From nobody Wed Jun 4 01:29: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 B76841A0109 for ; Wed, 4 Jun 2014 01:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 RqgtUKW54y0I for ; Wed, 4 Jun 2014 01:29:46 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F5A1A0100 for ; Wed, 4 Jun 2014 01:29:45 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 04 Jun 2014 10:29:37 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 4 Jun 2014 10:29:30 +0200 From: To: , Date: Wed, 4 Jun 2014 10:29:28 +0200 Thread-Topic: [sipcore] Precondition and status confirmation in regular two party calls Thread-Index: Ac98O2rwsVNJZE4ETuiaN5sjUMvSNADk2qXA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E1DD3D1465@HE113667.emea1.cds.t-internal.com> References: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> <39B5E4D390E9BD4890E2B31079006101126DE833@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126DE88C@ESESSMB301.ericsson.se> <201405301914.s4UJEYP2006272@hobgoblin.ariadne.com> In-Reply-To: <201405301914.s4UJEYP2006272@hobgoblin.ariadne.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/89h8Mgz9PQaRpyx5gvLKM1dprC4 Cc: ivo.sedlacek@ericsson.com Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls 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, 04 Jun 2014 08:29:47 -0000 Hi, I also agree on that. Do we need any documentation on that issue to help implementers on that? Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. Worle= y Gesendet: Freitag, 30. Mai 2014 21:15 An: sipcore@ietf.org Betreff: Re: [sipcore] Precondition and status confirmation in regular two = party calls > From: Ivo Sedlacek > The whole reason for the confirm-status attribute is to request a=20 > confirmation when resources becomes available. So if UA has *NOT*=20 > received the confirm-status attribute, then when resources of the UA=20 > becomes available, the UA should refrain from sending UPDATE (unless=20 > there is another reason, not related to resource reservation, for=20 > doing so). >=20 > Do you agree? Yes. It seems to be a case of "Do not send UPDATE unless there is a reason= to." Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jun 4 10:45: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 E87B01A0340 for ; Wed, 4 Jun 2014 10:45: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 WP2CUJaeBPIW for ; Wed, 4 Jun 2014 10:45:11 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E470D1A0259 for ; Wed, 4 Jun 2014 10:45:10 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id AFBC1o0070Fqzac51Hl4gK; Wed, 04 Jun 2014 17:45:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id AHl41o00C3ZTu2S3UHl4gU; Wed, 04 Jun 2014 17:45:04 +0000 Message-ID: <538F5B20.3000302@alum.mit.edu> Date: Wed, 04 Jun 2014 13:45:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> <39B5E4D390E9BD4890E2B31079006101126DE833@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126DE88C@ESESSMB301.ericsson.se> <201405301914.s4UJEYP2006272@hobgoblin.ariadne.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E1DD3D1465@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E1DD3D1465@HE113667.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401903904; bh=5l0GmIouHQEoe3346voivzc1PGpkKIDY9qOfdlTRkkM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=n0CQlNQmEg31wZ62PqDNaTOGiBZI4doHViyWXQ5+hgWWwpCsBb3nw5e4uPrLiEbHE 8nXOdqHG6hkeqPpcK4b2ZdkT9T/CIrSZXrR4H7Awz6J6wFGkfE8M/1kdLd1n7t0Dt8 p0S+s+AwfCqfuLjtZgabnZmNdNFbg1eWxWqzEiWMHdD6EPjgBSqw2dm0kxbrEU5OLG TXagUDdrO4miWeQoiEemt5LRIITXI6VpigPImpsNN5ZnixhhUObg9SGtkuVyrzfdTy bqZy0GRgl+FMTmfa+QK3MFkJDQI4ZfAiyGua4C716foTC2NcXz8xXBwmtCdno+1fBT cIWDA9HVjt8gQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/0FZa5wvcKnSOQNzEwjjemn2-sPM Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls 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, 04 Jun 2014 17:45:12 -0000 On 6/4/14 4:29 AM, R.Jesske@telekom.de wrote: > Hi, > I also agree on that. > Do we need any documentation on that issue to help implementers on that? This seems to simply be a quality of implementation issue and common sense rather than a specification issue. I don't see this as fundamentally different from the general notion that sending unneeded O/As is unwise and annoying. Thanks, Paul > Best Regards > > Roland > > -----Urspr�ngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. Worley > Gesendet: Freitag, 30. Mai 2014 21:15 > An: sipcore@ietf.org > Betreff: Re: [sipcore] Precondition and status confirmation in regular two party calls > >> From: Ivo Sedlacek > >> The whole reason for the confirm-status attribute is to request a >> confirmation when resources becomes available. So if UA has *NOT* >> received the confirm-status attribute, then when resources of the UA >> becomes available, the UA should refrain from sending UPDATE (unless >> there is another reason, not related to resource reservation, for >> doing so). >> >> Do you agree? > > Yes. It seems to be a case of "Do not send UPDATE unless there is a reason to." > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Jun 5 12:18: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 81D2A1A026F for ; Thu, 5 Jun 2014 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 7hBeRu2YXOMS for ; Thu, 5 Jun 2014 12:18:05 -0700 (PDT) Received: from mail-we0-f175.google.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with SMTP id 3E9D41A0282 for ; Thu, 5 Jun 2014 12:18:04 -0700 (PDT) Received: from mail-we0-f175.google.com ([74.125.82.175]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKU5DCZRGFHpNNT3sUocWUcKeq22tkvkxI@postini.com; Thu, 05 Jun 2014 12:17:58 PDT Received: by mail-we0-f175.google.com with SMTP id p10so1643920wes.20 for ; Thu, 05 Jun 2014 12:17:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xox/UxD7GRy4bfS9S5ifviByREzFEYA3pBENeK3CubE=; b=VKGPvtwESckWAnQswxVidtEffxzdpdX5BqsvAM8nqp7qgJSQG7bVqTUXK8ZWsoBptk 4xUU2uZbMCDuUHhyJOCdfO4sbk0beJXuTikSlzZPs7Aqy3dwT/rM/yCjBait+m6Jw0LZ mZN2Dhf8SdctBoGqtLjQtsbccwd+uOph/4A4SVWKdfU6Z5aIkqdZ5dBvtCESQCAZiP2m bgddE0j+xwjsGRLY7d+4NOH7rX1YjTKK6oKgL2xKGWwqP5LNHuUJW4mC11IttXloDzcE f7nUIPiAF944VxEMR1TKaYCu2ooM1fEgfYHk3rZO3dU2HD1KUGPfKnL7SUyKAkBNDt/7 nHqw== X-Gm-Message-State: ALoCoQmQf+C024TyxYhtNEkwLisfuKJaFKyE5gec+xZ77pEPTFEY4SDEHRqaOnOddPfGYIBvv+nxzxiVppQ7jGUJgIlwFqFl9pXOZaA1TWjH8gSDoyHjDchDqd3An5glf7iX14sHM3tS X-Received: by 10.180.210.237 with SMTP id mx13mr700293wic.49.1401995876641; Thu, 05 Jun 2014 12:17:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.210.237 with SMTP id mx13mr700280wic.49.1401995876553; Thu, 05 Jun 2014 12:17:56 -0700 (PDT) Received: by 10.194.190.8 with HTTP; Thu, 5 Jun 2014 12:17:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jun 2014 20:17:56 +0100 Message-ID: From: Michael Procter To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/7_Ofdhkvc52cYJns-IHMMWDX2C4 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-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, 05 Jun 2014 19:18:07 -0000 On 29 May 2014 18:45, Rifaat Shekh-Yusef wrote: > Hi Michael, > > Thanks for the review and feedback. > > Sure, I will add a section to talk about uses cases. > Would you be able to share your use cases to see if we can cover them in > this document? The main use-case that sprang to mind was if someone wanted to use an "Auto-Attendant-as-a-Service" app with their existing SIP trunking provider. In this scenario I imagined visiting AAaaS.example.com, and doing the normal HTTP-based OAUTH cycle with an account on itsp.example.net, so that itsp.example.net gives a suitable access token to AAaaS.example.com. Then, AAaaS.example.com could use the token in some way to perform the necessary SIP activity at the ITSP. With that in mind, I can see that I could use the flow in section 5, or something quite like it. Single purpose SIP credentials would also work, of course. The flow in section 4 involves passing my username/password for itsp.example.net to AAaaS.example.com, which I probably don't feel comfortable doing. Maybe this flow would make more sense from a trust perspective with something like a real phone rather than a webapp. A use-case would probably help me understand when this flow could be used. I don't know when I'd use the flow in section 3. If the client has an adequate UI, I don't see why this is better than using OAUTH over HTTP to start with. If it doesn't have an adequate UI, then this feels more like an automatic provisioning approach. This flow seems to move all the OAUTH machinery into SIP, but I don't know enough about the properties of OAUTH to say whether this is a good or bad idea yet! Again, a use-case would definitely help me understand what you want to achieve with this flow. Regards, Michael From nobody Sat Jun 7 13:48: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 65F411A01D9 for ; Sat, 7 Jun 2014 13:48:09 -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 2P5eRIMT9wDm for ; Sat, 7 Jun 2014 13:48:07 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001: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 548F51A01AA for ; Sat, 7 Jun 2014 13:48:07 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id to1so3842557ieb.15 for ; Sat, 07 Jun 2014 13:48:00 -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=H1ireuGkEFmWyLYgk0+TvNNVEd/DJdOLSEzmJ28jNZA=; b=jO/S7wj1K+fRYscxQdwalp8uLNw2KtK9Wc/0rbVRQSmZWKOPcwBpxB+6lGBqIE1WoP dlPBZuAUPYHz+7TJawB68s8DoNbUZSaMdQa/LDnF+2qSjH+t9OqmwRx6g1JctNRjiukU LrATTHndBaoHSi5FCw5B08WKYzf//Xew1JAcgdrzqNSKmfYOtuB6Piw76oE+CG9WhdR6 f1JS5b8CaiL/5EbqJDRzUv1chWoa5QXopR6YsPHjezkbxeWhmm6aB5BM5xi7ueLNRXty XrfTDimD77nqcrcDh4oy05+fPvOgzFduCrlI0eeVHs5lLET9EhVzDLgSpI3vBqsM8AlR iuNw== MIME-Version: 1.0 X-Received: by 10.50.253.195 with SMTP id ac3mr18566724igd.1.1402174079876; Sat, 07 Jun 2014 13:47:59 -0700 (PDT) Received: by 10.50.114.97 with HTTP; Sat, 7 Jun 2014 13:47:59 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Jun 2014 16:47:59 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Michael Procter Content-Type: multipart/alternative; boundary=001a1135f33af1c2f104fb4517a4 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/G2QjbVuNIxDndNjOw2bVglgFMLc Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-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: Sat, 07 Jun 2014 20:48:09 -0000 --001a1135f33af1c2f104fb4517a4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 5, 2014 at 3:17 PM, Michael Procter wrote: > On 29 May 2014 18:45, Rifaat Shekh-Yusef wrote: > > Hi Michael, > > > > Thanks for the review and feedback. > > > > Sure, I will add a section to talk about uses cases. > > Would you be able to share your use cases to see if we can cover them in > > this document? > > The main use-case that sprang to mind was if someone wanted to use an > "Auto-Attendant-as-a-Service" app with their existing SIP trunking > provider. In this scenario I imagined visiting AAaaS.example.com, and > doing the normal HTTP-based OAUTH cycle with an account on > itsp.example.net, so that itsp.example.net gives a suitable access > token to AAaaS.example.com. Then, AAaaS.example.com could use the > token in some way to perform the necessary SIP activity at the ITSP. > With that in mind, I can see that I could use the flow in section 5, > or something quite like it. Yes, the flow in section 5 would definitely address such a use case. > Single purpose SIP credentials would also > work, of course. > > True, but with the token-based solution the token could be used to get access to other services, and to control the level of service provided by an application. > The flow in section 4 involves passing my username/password for > itsp.example.net to AAaaS.example.com, which I probably don't feel > comfortable doing. Maybe this flow would make more sense from a trust > perspective with something like a real phone rather than a webapp. A > use-case would probably help me understand when this flow could be > used. > > Yes, real phones is what I had in mind for this one. This flow would allow the system to utilize the existing authentication mechanism (Digest), and still be able to enjoy the benefits of a token-based authorization. I don't know when I'd use the flow in section 3. If the client has an > adequate UI, I don't see why this is better than using OAUTH over HTTP > to start with. If it doesn't have an adequate UI, then this feels > more like an automatic provisioning approach. This flow seems to move > all the OAUTH machinery into SIP, but I don't know enough about the > properties of OAUTH to say whether this is a good or bad idea yet! > Again, a use-case would definitely help me understand what you want to > achieve with this flow. > > What I had in mind with this one is a 3rd party authorization server that could provide authorization for SIP and non-SIP clients for various services. With the Authorization Code Grant as defined in RFC6749, the authentication is not defined and typically done in the context of the code downloaded to the browser. The idea here is to introduce a new interface that would allow the client to directly authenticate with the authorization server to allow the SIP phones to utilize that existing authorization server. Regards, Rifaat > Regards, > > Michael > --001a1135f33af1c2f104fb4517a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 5, 2014 at 3:17 PM, Michael Procter &= lt;michael@voip.co.= uk> wrote:
On 29 May 2014 18:45, Rifaat Shekh-Yuse= f <rifaat.iet= f@gmail.com> wrote:
> Hi Michael,
>
> Thanks for the review and feedback.
>
> Sure, I will add a section to talk about uses cases.
> Would you be able to share your use cases to see if we can cover them = in
> this document?

The main use-case that sprang to mind was if someone wanted to use an=
"Auto-Attendant-as-a-Service" app with their existing SIP trunkin= g
provider. =A0In this scenario I imagined visiting AAaaS.example.com, and
doing the normal HTTP-based OAUTH cycle with an account on
itsp.example.net,= so that itsp.example= .net gives a suitable access
token to AAaaS.examp= le.com. =A0Then, AAaaS.example.com could use the
token in some way to perform the necessary SIP activity at the ITSP.
With that in mind, I can see that I could use the flow in section 5,
or something quite like it. =A0

Yes, the fl= ow in section 5 would definitely address such a use case.

=A0
Single purpose SIP credentials would also
work, of course.


True, but with the token-based solutio= n the token could be used to get access to other services, and to control t= he level of service provided by an application.

=A0
The flow in sec= tion 4 involves passing my username/password for
itsp.example.net = to AAaaS.example.com= , which I probably don't feel
comfortable doing. =A0Maybe this flow would make more sense from a trust perspective with something like a real phone rather than a webapp. =A0A
use-case would probably help me understand when this flow could be
used.


Yes, real phones is what I had in mind= for this one.=A0
This flow would allow the system to utilize the= existing authentication mechanism (Digest), and still be able to enjoy the= benefits of a token-based authorization.


I don't know when I'd use the flow in section 3. =A0If the client h= as an
adequate UI, I don't see why this is better than using OAUTH over HTTP<= br> to start with. =A0If it doesn't have an adequate UI, then this feels more like an automatic provisioning approach. =A0This flow seems to move all the OAUTH machinery into SIP, but I don't know enough about the
properties of OAUTH to say whether this is a good or bad idea yet!
Again, a use-case would definitely help me understand what you want to
achieve with this flow.


What I had in mind with this one is a = 3rd party authorization server that could provide authorization for SIP and= non-SIP clients for various services.
With the Authorization Cod= e Grant as defined in RFC6749, the authentication is not defined and typica= lly done in the context of the code downloaded to the browser.
The idea here is to introduce a new interface that would allow the cli= ent to directly authenticate with the authorization server to allow the SIP= phones to utilize that existing authorization server.

Regards,
=A0Rifaat

=A0
Regards,

Michael

--001a1135f33af1c2f104fb4517a4-- From nobody Sat Jun 7 16:35: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 678AC1A025D for ; Sat, 7 Jun 2014 16:35:08 -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 i24VyBAupRv3 for ; Sat, 7 Jun 2014 16:35:07 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2B01A0259 for ; Sat, 7 Jun 2014 16:35:07 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id BbZL1o0010mv7h054bb0C8; Sat, 07 Jun 2014 23:35:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id Bbaz1o00b3ZTu2S3XbazX6; Sat, 07 Jun 2014 23:35:00 +0000 Message-ID: <5393A1A3.6040904@alum.mit.edu> Date: Sat, 07 Jun 2014 19:34:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.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=1402184100; bh=NG9A0Y/v3lYE4eBwSv0foxzgRw1rbxPSFvFlU3VKqTg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Lqby8/RAMAhdVNsaZjIZur2ULcncXuSN+fxjVHlxwp8q4Y+f/86R+8Izlk5m8ij20 R0pMj7FksP0fcobpZGS8r03V4CDR+DLG6ugR0OgHszJznXmGYpbSgSd3kWjZXFoFJq ElZzd5Hr7IKVkdnlyPIQ43xF2ZE1yS3rGxZyg0kh1E9Ml6m79m31Wk7hTb7KE1jLx0 QENEp87iTcl3MWXc8LzbhzR216Q9NesT8Kzok6DqH5Uj9sLVCklmJtK9BbYCNo3e+I HHho0YjZ7jOBnLK7BcujheOZbc/jYb3L9FhchLW5IJFLmPvTMNY8xitbkbIEPsbt9M sNqL7ucF4nboA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/lMtWWdMbYSdjYTgoxT-uT08K5l8 Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-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: Sat, 07 Jun 2014 23:35:08 -0000 Rifaat, Thanks for taking a crack at this. I realize it is a rough first cut. Take these comments with a grain of salt - I may well just not understand what you intend. IIUC, the general intended flow is: - UA sends register, gets 302 with https URI - UA understands that to mean that it should use that URI to request authorization, to be later used to retry the register. I find a leap of faith there. This is very different semantics from normal handling of 3xx. 3xx responses *may* contain arbitrary URIs, including https URIs. But what exactly to do in such a case is not specified. It seems unreasonable to assume that it always means what this draft has assumed. Then there is a further leap of faith that after using the returned https uri one should then use the results of that to retry the original register request with the original sip URI, together with the new credentials. I'm sure we can find a way to signal that this is the intended behavior, but I suspect that a 3xx response is not the answer. I'm inclined to think that a 401, together with some new content in the response, would be a better way. Then, I guess all of that is preparatory to getting a token to be used to cause subsequent requests to be authenticated. What assumptions are you making here? Is it necessary to provide credentials to authenticate all requests? Or can this be avoided if you use a secure transport for the register and the subsequent requests? How does this relate to sip outbound? Can responses to outbound requests to the UA be authenticated? Is there a reason they don't need to be? Thanks, Paul From nobody Sun Jun 8 14:16: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 0CE461A043D for ; Sun, 8 Jun 2014 14:16:52 -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 65_BSgvQyRVT for ; Sun, 8 Jun 2014 14:16:49 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75B01A0435 for ; Sun, 8 Jun 2014 14:16:49 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id h3so3161702igd.13 for ; Sun, 08 Jun 2014 14:16:49 -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=l+SyfmT5FU+WrB1kCDTL2Fe/sqcrX1IRlcuHfqPL7YY=; b=WI7BVt1UOcbqtGO+TCdK22QOy8wJNFHAMJhUI9sWkoiDYuB0AGikWNIsLmsGpYnd49 Ko/4bciwVQeEva8oi/msDQJ8bGs+7HbfMtn/rEobqtBAEA5tEcgYSpISDSwYJZANjMC2 qo/PKFUp5WjAOQV4CvOkCtag4E2RIlPWOz0QQK3MLZC2ljqTQPHlkVj77h5cRU2oaMI9 NLPMCDpaPpWADuUSn/i/WXdIIglm/zWViwaml1YuRN5GkQMlRRqwnWvUlw0Q+7XvY5xa 5/pLIz9im7NC1FcB0vh0JABPPNzAi+R2xmohDbyvYr62mZgaRkD8CtZoAGJBppz2AwBl nwoA== MIME-Version: 1.0 X-Received: by 10.42.148.67 with SMTP id q3mr25278490icv.5.1402262209135; Sun, 08 Jun 2014 14:16:49 -0700 (PDT) Received: by 10.50.114.97 with HTTP; Sun, 8 Jun 2014 14:16:49 -0700 (PDT) In-Reply-To: <5393A1A3.6040904@alum.mit.edu> References: <5393A1A3.6040904@alum.mit.edu> Date: Sun, 8 Jun 2014 17:16:49 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=90e6ba6e8a14db89d804fb599c2c Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/tRymEbo1Yw9q4gP_tu1RD4ih8oU Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-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: Sun, 08 Jun 2014 21:16:52 -0000 --90e6ba6e8a14db89d804fb599c2c Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, Thanks for your review and comments. Please, see my reply inline... Regards, Rifaat On Sat, Jun 7, 2014 at 7:34 PM, Paul Kyzivat wrote: > Rifaat, > > Thanks for taking a crack at this. I realize it is a rough first cut. > > Take these comments with a grain of salt - I may well just not understand > what you intend. > > IIUC, the general intended flow is: > - UA sends register, gets 302 with https URI > - UA understands that to mean that it should use that URI > to request authorization, to be later used to retry > the register. > > Correct. I find a leap of faith there. This is very different semantics from normal > handling of 3xx. 3xx responses *may* contain arbitrary URIs, including > https URIs. But what exactly to do in such a case is not specified. It > seems unreasonable to assume that it always means what this draft has > assumed. > > Then there is a further leap of faith that after using the returned https > uri one should then use the results of that to retry the original register > request with the original sip URI, together with the new credentials. > > I'm sure we can find a way to signal that this is the intended behavior, > but I suspect that a 3xx response is not the answer. I'm inclined to think > that a 401, together with some new content in the response, would be a > better way. > > I was trying to capture the idea; the exact details of which code to use and what details to include in the body is obviously still open for discussion. 401 would be a reasonable approach too. > Then, I guess all of that is preparatory to getting a token to be used to > cause subsequent requests to be authenticated. What assumptions are you > making here? > > 1. Client Type: confidential 2. The mechanism must work over secure and non-secure transports. > Is it necessary to provide credentials to authenticate all requests? Or > can this be avoided if you use a secure transport for the register and the > subsequent requests? > > If the client and server are able to establish a mutually authenticated secure channel, then there is no need to authenticate every subsequent request; otherwise, I think it is needed. > How does this relate to sip outbound? Good question; I did not think about it before you mentioned it. Assuming all outbound proxies use the same authorization server, then I think that it would be possible to use the token the client receives from the first registrations to register with the other proxies. Can responses to outbound requests to the UA be authenticated? It is possible because both sides have a shared master-key that could be used by both sides to compute a proof-of-possession. Is there a reason they don't need to be? > > The only reason I can think of is performance impact on the server. I need to spend more time thinking about the implications of outbound on this. Regards, Rifaat > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --90e6ba6e8a14db89d804fb599c2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for your review and com= ments.
Please, see my reply inline...

Re= gards,
=A0Rifaat

<= br>
On Sat, Jun 7, 2014 at 7:34 PM, Paul Kyzivat= <pkyzivat@alum.mit.edu> wrote:
Rifaat,

Thanks for taking a crack at this. I realize it is a rough first cut.

Take these comments with a grain of salt - I may well just not understand w= hat you intend.

IIUC, the general intended flow is:
- UA sends register, gets 302 with https URI
- UA understands that to mean that it should use that URI
=A0 to request authorization, to be later used to retry
=A0 the register.


Correct.


=
I find a leap of faith there. This is very different semantics from normal = handling of 3xx. 3xx responses *may* contain arbitrary URIs, including http= s URIs. But what exactly to do in such a case is not specified. It seems un= reasonable to assume that it always means what this draft has assumed.

Then there is a further leap of faith that after using the returned https u= ri one should then use the results of that to retry the original register r= equest with the original sip URI, together with the new credentials.

I'm sure we can find a way to signal that this is the intended behavior= , but I suspect that a 3xx response is not the answer. I'm inclined to = think that a 401, together with some new content in the response, would be = a better way.


I was trying to capture the idea; the = exact details of which code to use and what details to include in the body = is obviously still open for discussion.
401 would be a reasonable= approach too.

=A0
Then, I guess all of that is preparatory to getting a token to be used to c= ause subsequent requests to be authenticated. What assumptions are you maki= ng here?


1. Client Type: confidential
2. The mechanism must work over secure and non-secure transports.

=A0
Is it necessary to provide credentials to authenticate all requests? Or can= this be avoided if you use a secure transport for the register and the sub= sequent requests?


If the client and server are able to e= stablish a mutually authenticated secure channel, then there is no need to = authenticate every subsequent request; otherwise, I think it is needed.

=A0
How does this relate to sip outbound?

Good question; I did not think about it before you mentioned it.
Assuming all outbound proxies use the same authorization server, then I th= ink that it would be possible to use the token the client receives from the= first registrations to register with the other proxies.


Can responses to outbo= und requests to the UA be authenticated?

It is possible because both sides have a shared master-= key that could be used by both sides to compute a proof-of-possession.
=A0

Is there a reason they don't need to be?


The only reason I can think of is perf= ormance impact on the server.


I nee= d to spend more time thinking about the implications of outbound on this.

Regards,
=A0Rifaat

=

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

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

--90e6ba6e8a14db89d804fb599c2c-- From nobody Wed Jun 11 11:34: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 DCD031B2815 for ; Wed, 11 Jun 2014 11:34:14 -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 lk4DMdJ8fmXb for ; Wed, 11 Jun 2014 11:34:14 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 242FB1A024D for ; Wed, 11 Jun 2014 11:34:14 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id D4c51o0051swQuc566aDwQ; Wed, 11 Jun 2014 18:34:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id D6aD1o00P3ZTu2S3b6aDjo; Wed, 11 Jun 2014 18:34:13 +0000 Message-ID: <5398A125.60202@alum.mit.edu> Date: Wed, 11 Jun 2014 14:34:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.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=1402511653; bh=2bNrz6kHJ2PuWycjkMtf/6bxbHaWfvKeLiv4UTExZYs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MkLO2kGEApTH57PyzzKyYQyaM8nCrDFFOhKIT3yPlwaqym899FbCsSdsWjVN+JUu0 FmDsTcsVrY+OsfL7/6nOrf8BBKGA63GNsrQqrsRSP2YfIQzmk796je0aiVlOo8qYrI 5fui7vWKuUJWrPn60Gt95eKXcu0r0qw125EQL0Zd+2L/U3gycthISHdWIOr8PRvxbS K4Mk1Vkl3kGyVk9jpeojiXV4I+mRNnpHky1qlqAaqJpMPkiBAQQoK7F3FdoVwM6aBI sJNDqiEI8pwlhpQ+EH+tSbjuyRT7wEwkms6dOSWLQvTZTpe5VrYdZjVEXzC/adFt6f BHhA4DIeK1hQw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/90rI4W4tKH3XkySPCnc5884MV2M Subject: [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: Wed, 11 Jun 2014 18:34:15 -0000 SIPCORE people, In London we agreed to request a milestone to work on dual-stack, and to seek to adopt Ollie's draft. Since then we have done those things. We now have a milestone, and we have a WG version of the draft: draft-ietf-sipcore-dns-dual-stack-00. So we have *started* the work. Now we need to finish it. (Our target date is June.) While the draft is in pretty good shape, ISTM it is a *little* bit premature to do a WGLC yet. There has been almost no discussion of the draft itself since London. I'm requesting that people please look at the draft and comment whether they think it says the right things. 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. Thanks, Paul From nobody Wed Jun 11 12:03: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 885931A025A for ; Wed, 11 Jun 2014 12:03: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 NCLYR7EIuxqp for ; Wed, 11 Jun 2014 12:03:23 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id EA1311A0249 for ; Wed, 11 Jun 2014 12:03:22 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id D6n71o00A1c6gX85D73NEz; Wed, 11 Jun 2014 19:03:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id D73N1o00A3ZTu2S3j73NQ8; Wed, 11 Jun 2014 19:03:22 +0000 Message-ID: <5398A7F9.7030101@alum.mit.edu> Date: Wed, 11 Jun 2014 15:03:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.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=1402513402; bh=z6UMMEFhhQivG2j4Uw6+uAgItu0jEd/QAZ1/DTMfDTY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N1ijPwPl/O/YNYVdv1BQ64/Z3/exdxAAEP0u+3Xk7iUVEzeHSGHP0VyaNoOOeYcny mvltN1+HUP74cURBIUMPeKiVSUzrNSlDkeOK43nLTxe891u982P8fyc9tUd2fxKbq8 fU1YJIVnmSWYSYkTDnJOs0KjD0cslqMNx4BniKtqHBh5w8UB6Qe+VBfraDceLYGgZ9 zAv9lV9Imsl/pHJoYKtQso6+8xvZpixhJ2AhkrvqJm64v3kwRaDIv9AcziNMcDGAfR ZmsLwJV9Jq/HMVGqCJbSx+sOLRRexNwzHo/nnmhkerIxsnwPJoGLG8ZCx8RDoG3cNF ZCyiMHEL08eug== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/f57Iv1qYQFlJUIAmz5yQZrUefBE Subject: [sipcore] Proceeding with dane-sip 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, 11 Jun 2014 19:03:24 -0000 SIPCORE people, Before the London meeting Olle Johansson submitted draft-johansson-dispatch-dane-sip to dispatch. It was dispatched to sipcore, and we had a sipcore session in London discussing it. That session didn't go smoothly. There was a great deal of disagreement over what, if anything, needs to be done to enable the use of DANE with sip. A poll of the room indicated profound confusion. The decision at the time was that we should focus on specific examples/use cases, and asked Olle to post some to the list. Olle subsequently posted on the list about that: > I don't think the confusion was about use cases at all or whether we need DANE or not - it was about whether the DANE group documents was enough, > if this is just a bump in the TLS stack or if we actually need to do something in SIPcore. Some people claimed > we need to do zero, nothing, nada. Some people (including me) claims we do need to document this, > especially since the SIP Domain certificate RFC is an update to RFC 3261 and DANE usage changes > the certificate contents. > > The DANE group is very clear that we do need to document our usage. Wes Hardaker pointed that out > several times during the discussion. It's documented in the DANE SRV drafts too. I still think use cases can help here. Suppose all sip implementations were capable of both 5922 and DANE. Then deployments would need to decide when it would be advantageous to use DANE rather than, or in addition to, DANE. What use cases can do is illustrate when DANE is advantageous. If we can agree on cases were we want to use DANE, then we will have better motivation to figure out what we must do to make that possible. This doesn't have to be just Olle - anybody can speak up. (We have the opportunity to discuss this further in Toronto, but unless we have some action on the list first then we probably won't.) Thanks, Paul From nobody Wed Jun 11 12:03:46 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 4B17B1B280C for ; Wed, 11 Jun 2014 12:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 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, MANGLED_HALF=2.3, 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 MWzKN3T2Gm0G for ; Wed, 11 Jun 2014 12:03:40 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFD81B280D for ; Wed, 11 Jun 2014 12:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=hal.gottfried@verizon.com; q=dns/txt; s=corp; t=1402513420; x=1434049420; h=from:to:date:subject:message-id:mime-version; bh=0eUz8ejmB+twnS33XQzsJfNbWhkJdgAq1mMIPgOGbi8=; b=oKzrBMsSquthiTEJKk2VuQp/WdfoyAqTEZ7YI7YTHcggJ/te8PwtDpG1 a0vFunx8MhHFr/ocmxW+IT/nAd9ucQCE350l8EyVgmUy6pFQAI9rLB61g u4LT5GrEtHcLVCNCCCMS9q7c3pLsXBnHMkfxQ2m17X2UxnWCxvw8/mWPK M=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 11 Jun 2014 19:03:39 +0000 From: "Gottfried, Hal F" X-IronPort-AV: E=Sophos;i="5.01,459,1400025600"; d="scan'208,217";a="768000036" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 11 Jun 2014 19:03:38 +0000 Received: from fhdp1lumxc7v13.us.one.verizon.com ([166.68.59.150]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Wed, 11 Jun 2014 15:03:38 -0400 To: "sipcore@ietf.org" Date: Wed, 11 Jun 2014 15:03:37 -0400 Thread-Topic: Finishing draft-ietf-sipcore-dns-dual-stack (Paul Kyzivat) Thread-Index: Ac+Fp9kMlkdZdkPqTRuejbidKzIBYg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E8A0C2E2F1560648B0FF20D8B91638C502C1109C78FHDP1LUMXC7V1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/iwF0FQLSLFCtvA-nSUGZdmKNrM0 Subject: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack (Paul Kyzivat) 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, 11 Jun 2014 19:03:43 -0000 --_000_E8A0C2E2F1560648B0FF20D8B91638C502C1109C78FHDP1LUMXC7V1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This may be due to me being newer to the group, but I am unsure of how to l= ocate the draft copy mentioned and add feedback or annotations to it. Regards: Hal F. Gottfried / Sr Consultant, Contact Center Consulting & Services hal.gottfried@one.verizon.com Verizon Advanced Services - Consulting & Integration Services (ASCIS) Mobile: 913-217-0994 | Follow Me: 913-815-4889 Out of Office Alert: 15-May through 16-May --_000_E8A0C2E2F1560648B0FF20D8B91638C502C1109C78FHDP1LUMXC7V1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This may = be due to me being newer to the group, but I am unsure of how to locate the= draft copy mentioned and add feedback or annotations to it.

 

&nbs= p;

Regards:

Hal F. Gottfri= ed / Sr Consultant, Contact Center Consulting &= ; Services 
 hal.gottfried@on= e.verizon.com

Verizon Advanced Service= s - Consulting & Integration Services (ASCIS)
Mobile: 913-217-0994 |  Follow M= e: 913-815-4889

Out of Office Alert:  15-May through 16-May

 

 

 

 

 

&= nbsp;

= --_000_E8A0C2E2F1560648B0FF20D8B91638C502C1109C78FHDP1LUMXC7V1_-- From nobody Wed Jun 11 12:17:01 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 0F7521B2860 for ; Wed, 11 Jun 2014 12:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_31=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 LSoLOnYlDHla for ; Wed, 11 Jun 2014 12:16:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E54111A0110 for ; Wed, 11 Jun 2014 12:16:56 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id 2254B93C2A1; Wed, 11 Jun 2014 19:16:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: <5398A7F9.7030101@alum.mit.edu> Date: Wed, 11 Jun 2014 20:16:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5398A7F9.7030101@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/A5cjBPnLSY2iELrq2JIU5NSTbzc Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 11 Jun 2014 19:16:59 -0000 On 11 Jun 2014, at 20:03, Paul Kyzivat wrote: > SIPCORE people, >=20 > Before the London meeting Olle Johansson submitted = draft-johansson-dispatch-dane-sip to dispatch. It was dispatched to = sipcore, and we had a sipcore session in London discussing it. >=20 > That session didn't go smoothly. There was a great deal of = disagreement over what, if anything, needs to be done to enable the use = of DANE with sip. A poll of the room indicated profound confusion. >=20 > The decision at the time was that we should focus on specific = examples/use cases, and asked Olle to post some to the list. Olle = subsequently posted on the list about that: >=20 >> I don't think the confusion was about use cases at all or whether we = need DANE or not - it was about whether the DANE group documents was = enough, >> if this is just a bump in the TLS stack or if we actually need to do = something in SIPcore. Some people claimed >> we need to do zero, nothing, nada. Some people (including me) claims = we do need to document this, >> especially since the SIP Domain certificate RFC is an update to RFC = 3261 and DANE usage changes >> the certificate contents. >>=20 >> The DANE group is very clear that we do need to document our usage. = Wes Hardaker pointed that out >> several times during the discussion. It's documented in the DANE SRV = drafts too. >=20 > I still think use cases can help here. Suppose all sip implementations = were capable of both 5922 and DANE. Then deployments would need to = decide when it would be advantageous to use DANE rather than, or in = addition to, DANE. What use cases can do is illustrate when DANE is = advantageous. >=20 > If we can agree on cases were we want to use DANE, then we will have = better motivation to figure out what we must do to make that possible. >=20 > This doesn't have to be just Olle - anybody can speak up. >=20 > (We have the opportunity to discuss this further in Toronto, but = unless we have some action on the list first then we probably won't.) >=20 RFC 5922 usage implies use of a CA that has a certificate that needs to = be installed on every single phone. It also use certificates that are = not available on the market - with SIP uri:s in the SAN extension = fields. DANE can be used with a CA in the same mode, but also with no CA, which = significantly makes it easier to use. The cost of managing a CA and = getting the CA chain out on every device is rather high, because it's a = complex operation if you want to have a trustworthy installation. /O From nobody Wed Jun 11 12:42: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 4BB241B2850 for ; Wed, 11 Jun 2014 12:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, 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 BSUGW3wYNUZs for ; Wed, 11 Jun 2014 12:42:29 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 26BBB1B289B for ; Wed, 11 Jun 2014 12:42:29 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id D7QS1o0041ap0As567iUrA; Wed, 11 Jun 2014 19:42:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id D7iU1o00L3ZTu2S3i7iUEE; Wed, 11 Jun 2014 19:42:28 +0000 Message-ID: <5398B124.2080901@alum.mit.edu> Date: Wed, 11 Jun 2014 15:42:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <5398A7F9.7030101@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=1402515748; bh=WJA7EofSo+Yk88iYBy5uNB/0JC61Qk6VWEGzLWYEvQo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wKSGApZtyxEFBeU5ye3HGJWC54nNXe9xMDbGEdzKYnihj8TvzpQVNcwTX/uw6MlSF e8VQ3j3fy5NCKlFLU6T5wV5jZsXBGDgf2oX7GGA1CflrBiQYzJxJAmq72+C/+tgE5o 5tebUZGX5Sn1aJ2C0v4hQmvGx+onzI5si9nXccXFYITiygkqi3fsT8YHOcbrC6PR1b g4zwOGZL0gwTkbLE/SbbSfoGmcI0UyFMIRzueyAVzTJ3+UObLQ8fFI6lJ4Caz2EW5P d8dCiBIjhxusHOmxpS+LyB8CW4h5EOz2pOgm6on6PTDiOXPIkoXjftSqIgE0gNpfRS 8SnPQlsScGNFA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/EIU2fSUoWwH-cUCRhfyqROs4k2o Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 11 Jun 2014 19:42:30 -0000 On 6/11/14 3:16 PM, Olle E. Johansson wrote: > On 11 Jun 2014, at 20:03, Paul Kyzivat wrote: >> I still think use cases can help here. Suppose all sip implementations were capable of both 5922 and DANE. Then deployments would need to decide when it would be advantageous to use DANE rather than, or in addition to, DANE. What use cases can do is illustrate when DANE is advantageous. >> >> If we can agree on cases were we want to use DANE, then we will have better motivation to figure out what we must do to make that possible. >> >> This doesn't have to be just Olle - anybody can speak up. >> >> (We have the opportunity to discuss this further in Toronto, but unless we have some action on the list first then we probably won't.) >> > > RFC 5922 usage implies use of a CA that has a certificate that needs to be installed on every single phone. It also use certificates that are not available on the market - with SIP uri:s in the SAN extension fields. > > DANE can be used with a CA in the same mode, but also with no CA, which significantly makes it easier to use. The cost of managing a CA and getting the CA chain out on every device is rather high, because it's a complex operation if you want to have a trustworthy installation. OK. Good start! Does anybody disagree that these are important reasons? Isn't it also the case that having certificates follow the DNS delegation chain also makes it much easier to deploy - avoiding the need to share certs among multiple servers? Thanks, Paul From nobody Wed Jun 11 13:48: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 665301A029D for ; Wed, 11 Jun 2014 13:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 FwcS3C2IRy9c for ; Wed, 11 Jun 2014 13:48:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBCB1A028A for ; Wed, 11 Jun 2014 13:48:05 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5BKm3RG003678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 Jun 2014 15:48:04 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5BKm3gr032634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Jun 2014 15:48:03 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5BKm20F028282 for ; Wed, 11 Jun 2014 15:48:03 -0500 (CDT) Message-ID: <5398C111.7000700@bell-labs.com> Date: Wed, 11 Jun 2014 15:50:25 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <5398A125.60202@alum.mit.edu> In-Reply-To: <5398A125.60202@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/XPkkp3-W7jR9d59TrEFQUKoQ30Q 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: Wed, 11 Jun 2014 20:48:07 -0000 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 -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Wed Jun 11 14:05: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 5BB0D1B28A2 for ; Wed, 11 Jun 2014 14:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_HALF=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 PKY7R1t9EGbP for ; Wed, 11 Jun 2014 14:05:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1191B289B for ; Wed, 11 Jun 2014 14:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=944; q=dns/txt; s=iport; t=1402520710; x=1403730310; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0YClX4GYfWzjE1vmf4h3ZTpyMaR2yOsWrncQwHQMQWY=; b=eNM0THbM9fwZfY9QErOlHxMTRx1JaiSfGwp/sPkb5i+1yd5CSHqfou5f oAoUT74HyytVVmpPtWKuOekPNJRbvWYm2Kh8Dms6pJHgxvHe9LwmSZi22 9aHHGwOrsE2UdC9jApn/sWXADhQ5YZjJGucSUvfkYpW6KGtPKrm7Va8MX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYFAJvDmFOtJA2B/2dsb2JhbABXA4MNUlYDqk4BAQEBAQEFAZFfhmtRAYEIFnWEAwEBAQMBAQEBNzQLBQsCAQg2ECcLJQEBBA4FiC4DCQgN0CoXhVyGWoFwIxAHEYMagRYEmi6BQpIJgzxsgUM X-IronPort-AV: E=Sophos;i="5.01,460,1400025600"; d="scan'208";a="332429583" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jun 2014 21:05:09 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5BL59RI015464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 21:05:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 16:05:09 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Gottfried, Hal F" Thread-Topic: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack (Paul Kyzivat) Thread-Index: Ac+Fp9kMlkdZdkPqTRuejbidKzIBYgAOuOKA Date: Wed, 11 Jun 2014 21:05:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <746DBA36EFCE914C98F5696872BEEBAA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HgTuK6C_iVBp4b6pNYM9nVbSDCc Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack (Paul Kyzivat) 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, 11 Jun 2014 21:05:15 -0000 Hi Hal -=20 The draft is located here: http://tools.ietf.org/html/draft-ietf-sipcore-d= ns-dual-stack Feedback can be sent to this list. Thanks, Gonzalo On Jun 11, 2014, at 3:03 PM, Gottfried, Hal F w= rote: > This may be due to me being newer to the group, but I am unsure of how to= locate the draft copy mentioned and add feedback or annotations to it. > =20 > =20 >=20 > Regards: >=20 > Hal F. Gottfried / Sr Consultant, Contact Center Consulting & Services=20 > hal.gottfried@one.verizon.com >=20 > Verizon Advanced Services - Consulting & Integration Services (ASCIS) > Mobile: 913-217-0994 | Follow Me: 913-815-4889 >=20 >=20 > Out of Office Alert: 15-May through 16-May >=20 > =20 >=20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jun 11 14:06: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 6979F1B28A6 for ; Wed, 11 Jun 2014 14:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_HALF=2.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 4FgAnoFk_jSd for ; Wed, 11 Jun 2014 14:06:39 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FAF1B28A4 for ; Wed, 11 Jun 2014 14:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=hal.gottfried@verizon.com; q=dns/txt; s=corp; t=1402520799; x=1434056799; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pFVbpM+7ufdvwTX30Ta99/Pw7vcY8YStdtDcrElQniE=; b=IxMRDkdyFn+dQj2SPR5FBkVvhncsWTTYGzjW2Cn+pcZd0sFXm7sdsjoH zCVURT1mM7wm0KZHvDmwLaePBhr1XwcnqY78pPgcVaPaVaf8/isyrY7qJ n4N8A7bFTu51QmjobMiDAHvn2JNUjRwoBVJHgi9VQc5eI0Wuw0n9c6ZIy s=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 11 Jun 2014 21:06:22 +0000 From: "Gottfried, Hal F" X-IronPort-AV: E=Sophos;i="5.01,460,1400025600"; d="scan'208";a="768116845" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 11 Jun 2014 21:06:21 +0000 Received: from fhdp1lumxc7v13.us.one.verizon.com ([166.68.59.150]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 11 Jun 2014 17:06:20 -0400 To: "Gonzalo Salgueiro (gsalguei)" Date: Wed, 11 Jun 2014 17:06:18 -0400 Thread-Topic: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack (Paul Kyzivat) Thread-Index: Ac+Fp9kMlkdZdkPqTRuejbidKzIBYgAOuOKAAAp2ONA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/H00gkLnv72bLU8NHWQxoUjcItq8 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack (Paul Kyzivat) 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, 11 Jun 2014 21:06:40 -0000 Thank you. Regards: Hal F. Gottfried=A0/=A0Sr Consultant, Contact Center Consulting & Services= =A0 Verizon Advanced Services - Consulting & Integration Services (ASCIS) -----Original Message----- From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]=20 Sent: Wednesday, June 11, 2014 4:05 PM To: Gottfried, Hal F Cc: sipcore@ietf.org Subject: Re: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack (Paul Ky= zivat) Hi Hal -=20 The draft is located here: http://tools.ietf.org/html/draft-ietf-sipcore-d= ns-dual-stack Feedback can be sent to this list. Thanks, Gonzalo On Jun 11, 2014, at 3:03 PM, Gottfried, Hal F w= rote: > This may be due to me being newer to the group, but I am unsure of how to= locate the draft copy mentioned and add feedback or annotations to it. > =20 > =20 >=20 > Regards: >=20 > Hal F. Gottfried / Sr Consultant, Contact Center Consulting & Services =20 > hal.gottfried@one.verizon.com >=20 > Verizon Advanced Services - Consulting & Integration Services (ASCIS) > Mobile: 913-217-0994 | Follow Me: 913-815-4889 >=20 >=20 > Out of Office Alert: 15-May through 16-May >=20 > =20 >=20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jun 11 16:35:03 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 A17C31B28E0 for ; Wed, 11 Jun 2014 16:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 VqRdm_zKQG4m for ; Wed, 11 Jun 2014 16:35:01 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AF21B28DF for ; Wed, 11 Jun 2014 16:35:01 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id BD9921E0C3; Wed, 11 Jun 2014 23:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1402529697; bh=+yPSXWKGC9QTT2wSCtnmrsLjbGwueRx40u8ddJMlBBk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YKeP8FMR0CiALWThIrJgd6qI8ihOgfJXNNywBlfFb6T/vE4cKkx1wIsPypCIs0Uuh +azclKmhaQuUjZZV+dj4mH56Jbh13YYoxxEAipniMAyzJE6yy+FLB938BKhwv1MMSc qd+kZAVn7JEBldG2/BimunPznElV6vU+EVl52x74= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 3873F6001E; Wed, 11 Jun 2014 23:23:41 +0000 (UTC) From: James Cloos To: Paul Kyzivat In-Reply-To: <5398B124.2080901@alum.mit.edu> (Paul Kyzivat's message of "Wed, 11 Jun 2014 15:42:28 -0400") References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 11 Jun 2014 19:23:41 -0400 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140611:pkyzivat@alum.mit.edu::xVUXPyL+j2deApbC:00000000000000000000000000000000000000070xaZ X-Hashcash: 1:30:140611:oej@edvina.net::Duqmq9Snnt7NahmK:00AQbBq X-Hashcash: 1:30:140611:sipcore@ietf.org::eTOF76AoOJ7dDpFE:Y1Ha+ Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/I74FAv0F-QkymjB6Yqp8dIp_sC8 Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Proceeding with dane-sip 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, 11 Jun 2014 23:35:02 -0000 >>>>> "PK" == Paul Kyzivat writes: PK> Isn't it also the case that having certificates follow the DNS PK> delegation chain also makes it much easier to deploy - avoiding the PK> need to share certs among multiple servers? Yes. With the oob draft nearing publication, sipcore should include spki configurations when discussing dane. With that, the tls server only sends the SPKI, which is to be verified out of band. Dane's 3 1 1 tlsa records are a perfect way to verify them. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Jun 12 03:11:56 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 E7F861B2833 for ; Thu, 12 Jun 2014 03:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_31=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 bL-fNULFNxNy for ; Thu, 12 Jun 2014 03:11:53 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C8BFB1B2830 for ; Thu, 12 Jun 2014 03:11:52 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id A2E5093C2A1; Thu, 12 Jun 2014 10:11:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: <5398B124.2080901@alum.mit.edu> Date: Thu, 12 Jun 2014 11:11:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/N3eftRNFZjntDCVxM9h91CFeKoo Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 12 Jun 2014 10:11:55 -0000 On 11 Jun 2014, at 20:42, Paul Kyzivat wrote: > On 6/11/14 3:16 PM, Olle E. Johansson wrote: >> On 11 Jun 2014, at 20:03, Paul Kyzivat wrote: >>> I still think use cases can help here. Suppose all sip = implementations were capable of both 5922 and DANE. Then deployments = would need to decide when it would be advantageous to use DANE rather = than, or in addition to, DANE. What use cases can do is illustrate when = DANE is advantageous. >>>=20 >>> If we can agree on cases were we want to use DANE, then we will have = better motivation to figure out what we must do to make that possible. >>>=20 >>> This doesn't have to be just Olle - anybody can speak up. >>>=20 >>> (We have the opportunity to discuss this further in Toronto, but = unless we have some action on the list first then we probably won't.) >>>=20 >>=20 >> RFC 5922 usage implies use of a CA that has a certificate that needs = to be installed on every single phone. It also use certificates that are = not available on the market - with SIP uri:s in the SAN extension = fields. >>=20 >> DANE can be used with a CA in the same mode, but also with no CA, = which significantly makes it easier to use. The cost of managing a CA = and getting the CA chain out on every device is rather high, because = it's a complex operation if you want to have a trustworthy installation. >=20 > OK. Good start! >=20 > Does anybody disagree that these are important reasons? >=20 > Isn't it also the case that having certificates follow the DNS = delegation chain also makes it much easier to deploy - avoiding the need = to share certs among multiple servers? Thanks for the reminder: Another benefit is that the server certificate only needs the server = host name. With DANE you don't change the server cert when adding a new = domain. With traditional certs - using DANE or not - you need a new certificate = for any change in hosted domains. /O= From nobody Thu Jun 12 07:58: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 621EA1B2A7D for ; Thu, 12 Jun 2014 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, 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 J53fez9kF3Wv for ; Thu, 12 Jun 2014 07:58:32 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id BB5531B2A81 for ; Thu, 12 Jun 2014 07:58:31 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id DPMt1o0051YDfWL5ASyXv1; Thu, 12 Jun 2014 14:58:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id DSyW1o01J3ZTu2S3gSyWL1; Thu, 12 Jun 2014 14:58:31 +0000 Message-ID: <5399C016.7090200@alum.mit.edu> Date: Thu, 12 Jun 2014 10:58:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Richard Barnes , Cullen Jennings , Jon Peterson , Robert Sparks References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> In-Reply-To: <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> 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=1402585111; bh=PNnP4rgVZoYCLDpsjYRe4SggVGxFT9ze6oHvlgfOx88=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tc3C+3uew0VABq5Yn5XTXHIU8nkad0Xy31HxCDjtA8d46GCpcEtPqzcQiFiU3mjp9 xQUCqoeNVcy3IBf//zI3gB0zCsig0akDqYdsleCfBdiLexKJ8VptPJYhx1nU3Oh5nC oyeKNNGoMl8sz/uARz04sVQQzVRTmsGkgTtZCDyZeGrpjEzIIbas+xUpTMHrQncimj ReKJTdZOs5U9jXVOPS9E2arKoLicRGYxPYeli9qoT0Dc+O9J+zhR6Z4xSH5DFMmtJR U7S7CHFPY1pVqaMAXaqv8KPopbeCKoBFq+VmxFsQ1EdxUdpHyfs9M6xqCQgY8kHhM+ KdouS4s3JMj/A== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/pkF8uNy4LF_BbeM4fOeCgmZfDT8 Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 12 Jun 2014 14:58:33 -0000 Richard, Robert, Cullen, John, I believe you were the people most concerned with having use cases for DANE. Do the cases brought up in this thread sufficient to satisfy you. (Certainly these cases can be explained in more detail, but in general to you consider them valid?) Thanks, Paul On 6/12/14 6:11 AM, Olle E. Johansson wrote: > > On 11 Jun 2014, at 20:42, Paul Kyzivat wrote: > >> On 6/11/14 3:16 PM, Olle E. Johansson wrote: >>> On 11 Jun 2014, at 20:03, Paul Kyzivat wrote: >>>> I still think use cases can help here. Suppose all sip implementations were capable of both 5922 and DANE. Then deployments would need to decide when it would be advantageous to use DANE rather than, or in addition to, DANE. What use cases can do is illustrate when DANE is advantageous. >>>> >>>> If we can agree on cases were we want to use DANE, then we will have better motivation to figure out what we must do to make that possible. >>>> >>>> This doesn't have to be just Olle - anybody can speak up. >>>> >>>> (We have the opportunity to discuss this further in Toronto, but unless we have some action on the list first then we probably won't.) >>>> >>> >>> RFC 5922 usage implies use of a CA that has a certificate that needs to be installed on every single phone. It also use certificates that are not available on the market - with SIP uri:s in the SAN extension fields. >>> >>> DANE can be used with a CA in the same mode, but also with no CA, which significantly makes it easier to use. The cost of managing a CA and getting the CA chain out on every device is rather high, because it's a complex operation if you want to have a trustworthy installation. >> >> OK. Good start! >> >> Does anybody disagree that these are important reasons? >> >> Isn't it also the case that having certificates follow the DNS delegation chain also makes it much easier to deploy - avoiding the need to share certs among multiple servers? > > Thanks for the reminder: > > Another benefit is that the server certificate only needs the server host name. With DANE you don't change the server cert when adding a new domain. > > With traditional certs - using DANE or not - you need a new certificate for any change in hosted domains. > > /O > From nobody Thu Jun 12 08:21: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 8F89E1A0263 for ; Thu, 12 Jun 2014 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-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 k1hXQ4qbPmVA for ; Thu, 12 Jun 2014 08:21:08 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3AE1A0370 for ; Thu, 12 Jun 2014 08:21:08 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5CFKCMK014694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jun 2014 10:20:12 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5CFKCG8020966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jun 2014 10:20:12 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5CFKAZg022855; Thu, 12 Jun 2014 10:20:12 -0500 (CDT) Message-ID: <5399C5BA.20503@bell-labs.com> Date: Thu, 12 Jun 2014 10:22:34 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Olle E. Johansson" , Paul Kyzivat References: <5398A7F9.7030101@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ndUuOE9rNYscAaZPtMu_isl1xyg Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 12 Jun 2014 15:21:10 -0000 On 06/11/2014 02:16 PM, Olle E. Johansson wrote: > RFC 5922 usage implies use of a CA that has a certificate that needs > to be installed on every single phone. A bit of a correction here. RFC5922 does not imply that the certificate needs to be installed on "every single phone". Instead, the expectation is that the certificate is installed on a domain proxy (hence the moniker of the draft, domain certificate). There is no normative language in rfc5922 that requires a client (i.e., a UA) to possess a certificate. > It also use certificates that are not available on the market - with > SIP uri:s in the SAN extension fields. True; however, at the time work on rfc5922 was done, an alternative identity specific to SIP encoded in the subjectAltName was viewed as being advantageous. > DANE can be used with a CA in the same mode, but also with no CA, > which significantly makes it easier to use. The cost of managing a CA > and getting the CA chain out on every device is rather high, because > it's a complex operation if you want to have a trustworthy > installation. I believe as we study whether or not the DANE model applies to SIP, we should remove the need for UA certificates as a comparative factor. RFC5922 does not require UAs to have a certificate. Yes, domain servers need to possess a certificate, but that is no different than web servers possessing one, as is prevalent today. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Thu Jun 12 08:26: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 C38A91A0263 for ; Thu, 12 Jun 2014 08:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 GcWVKJ4TDH7p for ; Thu, 12 Jun 2014 08:26:32 -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 9FC441A00FA for ; Thu, 12 Jun 2014 08:26:32 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so950703qcv.38 for ; Thu, 12 Jun 2014 08:26:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=MZCGwzEv4Pjzfi0fMVhfudawfbLm92pABmhzwp1xRSQ=; b=Iv0hpS44eGcS/HzpORpJbcUTYahJn0AN/FEj0l3osPpDxrHBec371iC66OIOjmS9wd zS2cp39ZI/Rskk5D18DJx/Hlrs9GGHJb7zvjcpoOgI6P65isqZPB/YRhCN1QAQuJz/y3 W4yo5L07HqryJAItHWZq9xDDkvxA6mOUycWxbisO3I/x65NA9J2eVYOJG7aguuY4AHpc Q55tK9f7UF4/e2/u5wmtb9ytKzfbhy7RwrwrqD3d8BOWb7tjiSJXUAoNjL4ndon6Ihae MkRE2BBfREYwNWe+ptdTMXrM/Q29WKrFF9LakSBuWFNJT+QINc2lSXt+Z+GKtFxUUCV8 I8mw== X-Gm-Message-State: ALoCoQnULOfjWKg0qq2Ubqr2I2xZeB7zjeBe1QQHi+uNtuomfOcaUKVqGOLIPEGzFOcKReOhzG/p X-Received: by 10.140.109.201 with SMTP id l67mr59123179qgf.72.1402586791796; Thu, 12 Jun 2014 08:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Thu, 12 Jun 2014 08:26:11 -0700 (PDT) In-Reply-To: <5398B124.2080901@alum.mit.edu> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 12 Jun 2014 17:26:11 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/mNi8I5Q2ubokj61HKrrYK34BcrI Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Proceeding with dane-sip 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, 12 Jun 2014 15:26:33 -0000 2014-06-11 21:42 GMT+02:00 Paul Kyzivat : >> >> RFC 5922 usage implies use of a CA that has a certificate that needs to = be >> installed on every single phone. It also use certificates that are not >> available on the market - with SIP uri:s in the SAN extension fields. >> >> DANE can be used with a CA in the same mode, but also with no CA, which >> significantly makes it easier to use. The cost of managing a CA and gett= ing >> the CA chain out on every device is rather high, because it's a complex >> operation if you want to have a trustworthy installation. > > > OK. Good start! > > Does anybody disagree that these are important reasons? I event consider that these are *the reasons* :) --=20 I=C3=B1aki Baz Castillo From nobody Thu Jun 12 08:29: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 6B2621A0370 for ; Thu, 12 Jun 2014 08:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 HIBFBjtrgas0 for ; Thu, 12 Jun 2014 08:29:32 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B951A00A2 for ; Thu, 12 Jun 2014 08:29:32 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so2215745qcy.29 for ; Thu, 12 Jun 2014 08:29:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qbhX+tYtnCUE4NLkdP2/gzlhLqDNtXf/KkWBEYWvTuY=; b=MsFRfp2lY1G9nE+PRL82XqkZAakncdLIG/TgzlSWjFd6G7PowNvZAGwUiwrxKzEgCZ gKzGEoA27mkipJuF7jbuI2/ja1xwzncc/nWZCM/G1vUiP2sCbIPE++x1V/X6tpwQlYtl d3sRNstbjc44iO075aazvfEhSqFQwYxh03JmcWW07oGmXcWy2CZpHJ0TaG+1tRMZolbS zEMfDrmoxf6YdD3mwao2CVCjPpe6lLtSirjE5rO2OUzZ8ovd6B4xLu4oJKi9Gpn5oIn3 UhSNkZFaEhH/NC/QzcQokj126JLGbvRq4tDLPZeQl7mSqsRW8W5yirMR+c/fivRI3mZ3 pFzQ== X-Gm-Message-State: ALoCoQn8r6y4ndBqUbDw/4BekzhtFOhYHEgWKzBtJfzT+rsq79yDF1yEY3ktqzzx77PaQ4hhvRas X-Received: by 10.140.109.201 with SMTP id l67mr59149479qgf.72.1402586971259; Thu, 12 Jun 2014 08:29:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Thu, 12 Jun 2014 08:29:11 -0700 (PDT) In-Reply-To: <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 12 Jun 2014 17:29:11 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/VhDnXwLrZsCDVw8i-qEP5iC_Vaw Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 12 Jun 2014 15:29:33 -0000 2014-06-12 12:11 GMT+02:00 Olle E. Johansson : > With traditional certs - using DANE or not - you need a new certificate f= or any change in hosted domains. Well, not exactly IMHO. If you run NAPTR/SRV records then the SIP UA will try to contact "sip:myserver.com". After DNS NAPTR/SRV/A/AAAA resolution that will point to any hostname. That's not a problem. The certificate in those different servers must just contain "myserver.com". Well, all what I've said gets broken for in-dialog requests, you know. But that's another topic. --=20 I=C3=B1aki Baz Castillo From nobody Thu Jun 12 08:35:31 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 6CACC1B2A1A for ; Thu, 12 Jun 2014 08:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 YQ4lssQCoTqi for ; Thu, 12 Jun 2014 08:35:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB81A0127 for ; Thu, 12 Jun 2014 08:35:26 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id 8182D93DE3F; Thu, 12 Jun 2014 15:34:41 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 12 Jun 2014 16:35:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/h_tRTjeVxodfsk3ovnYSuKHHhh4 Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 12 Jun 2014 15:35:29 -0000 On 12 Jun 2014, at 16:29, I=F1aki Baz Castillo wrote: > 2014-06-12 12:11 GMT+02:00 Olle E. Johansson : >> With traditional certs - using DANE or not - you need a new = certificate for any change in hosted domains. >=20 > Well, not exactly IMHO. If you run NAPTR/SRV records then the SIP UA > will try to contact "sip:myserver.com". After DNS NAPTR/SRV/A/AAAA > resolution that will point to any hostname. That's not a problem. The > certificate in those different servers must just contain > "myserver.com". >=20 Not according to the SIP Domain cert RFC, I=F1aki. You need to check for=20= the SIP domain in the SIP URI in the SAN fields. /O > Well, all what I've said gets broken for in-dialog requests, you know. > But that's another topic. >=20 >=20 >=20 > --=20 > I=F1aki Baz Castillo > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jun 12 09:33: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 6D58D1B27CE for ; Thu, 12 Jun 2014 09:33:34 -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 5CD-N3q7rgFT for ; Thu, 12 Jun 2014 09:33:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1471F1A01AA for ; Thu, 12 Jun 2014 09:33:32 -0700 (PDT) X-AuditID: c1b4fb2d-f79776d000001085-9c-5399d65bb2f3 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 65.1E.04229.B56D9935; Thu, 12 Jun 2014 18:33:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 18:33:31 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: SIP OAuth: Information element to carry token Thread-Index: Ac+GXAtV4bffJBdGSQCga8JWstB7EA== Date: Thu, 12 Jun 2014 16:33:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@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.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D35F7BCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW70tZnBBr//SFh8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGY8nvGAr+CtQcXfeLtYGxu98XYwcHBICJhJbzop2MXICmWIS F+6tZ+ti5OIQEjjKKLGnbT07hLOYUeJMywp2kAY2AQuJ7n/aIA0iApoSy79tZQexhQXMJLpO HmGGiFtLzL+5HMrWk1h5Zh0riM0ioCqx79QyRhCbV8BX4kLnbLBeRqDF30+tYQKxmQXEJW49 mc8EcZCAxJI955khbFGJl4//sULYShI/NlxigajPl7j78y4TxExBiZMzn7BMYBSahWTULCRl s5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6 eaklmxiBEXFwy2/dHYyrXzseYhTgYFTi4VWYOSNYiDWxrLgy9xCjNAeLkjjvJY3qYCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2Mrs+ETB1YfJStPIWuRdisyJ32nDU0rLclQmhek9bfu89s OxcpzLizuPrOc+5lvbuOOpQ17jP5MvXt7tWT+m5/eyxizhZ+1ek3w/dAxmVyTDt2/5eW7cyy zNoaMVNl/+GHC/istRs3run5rBW7o/rE3/jjvLI3bphEeLPFSlrXOa/ZvfiU3tr/SizFGYmG WsxFxYkA03nrsWkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/wFLlJ1oF0X_oDdDnZtuy9WSw--k Subject: [sipcore] SIP OAuth: Information element to carry token 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, 12 Jun 2014 16:33:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D35F7BCESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was taking a look at draft-yusef-sipcore-sip-oauth-00. In section 4, I see that the OAuth token is carried in a message body. Is t= here a reason why one could not use the SIP Authorization header field? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D35F7BCESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I was taking a look at <= span lang=3D"fi"> draft-yusef-sipcore-sip-oauth-00.
 
In sec= tion 4, I see that the OAuth token is carried in a message body. Is there a= reason why one could not use  the SIP Authorization header field= ?
 
Regard= s,
 
Christ= er
--_000_7594FB04B1934943A5C02806D1A2204B1D35F7BCESESSMB209erics_-- From nobody Thu Jun 12 09:57:56 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 5311F1B27B6 for ; Thu, 12 Jun 2014 09:57:54 -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 rV137j2yk1ud for ; Thu, 12 Jun 2014 09:57:52 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3411B27AC for ; Thu, 12 Jun 2014 09:57:52 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so1389901iec.27 for ; Thu, 12 Jun 2014 09:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S3B3b0+RGZHTTIroWhs+Dnmwodf10uuPCZrX7lMComE=; b=hQPMht90V9UU/MKaAz3SFgQ/NfZO0WDTbMxjKyhdDyu+B6+/KlTE+rFd6UF1JI9q3Y 6QeyZAhnrpvYi4KuslNJUTx+ZJEY9c1F8gFpNoz6vSLzawQkmQal6igih+/1aQOZDBET o+8PngqJSrLESDJo3X2WRoltcCgKO2IzS/YAJqye1508E2vuI1OuWDMxzfkWJ/FLrssV PdoLL1wHUseBOBHcONLAYI8Quvd+VT9hvQriD9oyxE87FHDDlmEQcBdKJjlKE9bKbmdf 1t/ZUNkLqkdr1EqAowminOEHaupy0vhfaitGkdt94Jpnrb05aZVU9r9v4vuKnZs8I23b /RTw== MIME-Version: 1.0 X-Received: by 10.42.120.15 with SMTP id d15mr57004883icr.35.1402592271755; Thu, 12 Jun 2014 09:57:51 -0700 (PDT) Received: by 10.50.114.97 with HTTP; Thu, 12 Jun 2014 09:57:51 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> Date: Thu, 12 Jun 2014 12:57:51 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Christer Holmberg Content-Type: multipart/alternative; boundary=90e6ba613c3a1f7b5204fba67673 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/uUiwLpNiGf5LoZ4--cgRQBsIrcA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 12 Jun 2014 16:57:54 -0000 --90e6ba613c3a1f7b5204fba67673 Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, I tried to keep this proposal aligned with approach taken by RFC6749, but I think that using Authorization header would be a valid option too. Is there any reason that you prefer it to be carried in the Authorization header instead of the message body? Regards, Rifaat On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I was taking a look at draft-yusef-sipcore-sip-oauth-00. > > In section 4, I see that the OAuth token is carried in a message body. Is > there a reason why one could not use the SIP Authorization header field? > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --90e6ba613c3a1f7b5204fba67673 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,

I tried to keep this propo= sal aligned with approach taken by RFC6749, but I think that using Authoriz= ation header would be a valid option too.
Is there any reason tha= t you prefer it to be carried in the Authorization header instead of the me= ssage body?

Regards,
=A0Rifaat

=


On Thu, Jun 1= 2, 2014 at 12:33 PM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:
Hi,
=A0
I was taking a look at draft-yusef-sipcore-sip-oauth-00.
= =A0
In sectio= n 4, I see that the OAuth token is carried in a message body. Is there a re= ason why=A0one could not use=A0 the SIP Authorization header field?<= /div>
= =A0
Regards,<= /span>
= =A0
Christer<= /span>

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


--90e6ba613c3a1f7b5204fba67673-- From nobody Thu Jun 12 11:03:41 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 28CCB1A01F3 for ; Thu, 12 Jun 2014 11:03:40 -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 eS_eilVxlWej for ; Thu, 12 Jun 2014 11:03:38 -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 01D841A015C for ; Thu, 12 Jun 2014 11:03:37 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-4e-5399eb77fbfd Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FE.B0.25910.77BE9935; Thu, 12 Jun 2014 20:03:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 20:03:35 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP OAuth: Information element to carry token Thread-Index: Ac+GXAtV4bffJBdGSQCga8JWstB7EP//5UaAgAAzljQ= Date: Thu, 12 Jun 2014 18:03:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D35FAB8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D35FAB8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rrfi9cxggwmzuC12vmhls/j6YxOb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxbOpC9oI1KhW3jss3MG6X72Lk5JAQMJFY fOc9O4QtJnHh3nq2LkYuDiGBo4wSXW9vsYIkhAQWM0o8WC/TxcjBwSZgIdH9TxskLCKgJ9H+ dyETiM0soCnxaOdeMFtYwEWi69diNogaV4mNq5azQNhWEuePv2QEsVkEVCWeLl8NVs8r4Ctx Zm8PM8TeSYwSZ+acBiviFAiUWLrlIlgRI9Bx30+tgVomLnHryXwmiKMFJJbsOc8MYYtKvHz8 jxXCVpTYebadGeRmZoF8iZZLZhC7BCVOznzCMoFRdBaSSbMQqmYhqYIo0ZO4MXUKG4StLbFs 4WtmCFtXYsa/QyzI4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbawS2/DXYwvnzu eIhRgINRiYdXYeaMYCHWxLLiytxDjNIcLErivBc1qoOFBNITS1KzU1MLUovii0pzUosPMTJx cEo1MHqUhpy2rvhqf8et3O0O793Srwn6QRwGB6zEwq/OOSWsKjZbYt8q6V0Tdh8Kvnviwkkj t1NrVJeEXWL9sVPzcLenS8kc+bXvl33KuGzg+d6gaenMAKl5fPsnsMafeD19YnthrtbpmiPZ 2YEXHq9wYN00jy9PKkx6TXrv57M8nLMfCFz4eGi+XIgSS3FGoqEWc1FxIgCcdHThlQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/dmlz89icyHRFBnSrUs0EKgXC9PI Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 12 Jun 2014 18:03:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D35FAB8ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >I tried to keep this proposal aligned with approach taken by RFC6749, but = I think that using >Authorization header would be a valid option too. >Is there any reason that you prefer it to be carried in the Authorization = header instead of the message >body? I was just thinking it would be more alligned with other mechanisms used in= SIP. Also, using a message body for this purpose seems a little "overkill" in my= opinion. Regards, Christer On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg > wrote: Hi, I was taking a look at draft-yusef-sipcore-sip-oauth-00. In section 4, I see that the OAuth token is carried in a message body. Is t= here a reason why one could not use the SIP Authorization header field? Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1D35FAB8ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

>I tried to keep this proposal aligned with approach taken by RFC67= 49, but I think that using >Authorization header would be a valid option= too.
>Is there any reason that you prefer it to be carried in the Author= ization header instead of the message >body?
 
I was just thinking it would be more alligned with other mechanisms us= ed in SIP.
 
Also, using a message body for this purpose seems a little "= overkill" in my opinion.
 
Regards,
 
Christer
 
 
 
On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:
Hi,
 
I was taking a look at <= span lang=3D"fi"> draft-yusef-sipcore-sip-oauth-00.
 
In sec= tion 4, I see that the OAuth token is carried in a message body. Is there a= reason why one could not use  the SIP Authorization header field= ?
 
Regard= s,
 
Christ= er

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


--_000_7594FB04B1934943A5C02806D1A2204B1D35FAB8ESESSMB209erics_-- From nobody Thu Jun 12 15:23: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 04D6E1A02CB for ; Thu, 12 Jun 2014 15:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 etBxKaRFGsy7 for ; Thu, 12 Jun 2014 15:23:39 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D551A0271 for ; Thu, 12 Jun 2014 15:23:38 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id w8so2385288qac.36 for ; Thu, 12 Jun 2014 15:23:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=lV/9AyOnntbWNrmyx6UAYkC+hl2OR0STw2/H+dxRHB8=; b=LEsLSejjOQ5EZMIIaZDcVNM/9ZfwIulbE+vfRloR+An/VAnHI4liwMOPzkLlqOJSNH 5XKFue3B8QhE38O3OeVVnc8advduKD0A4Jw6pG3z906Q4ctEO9GAH4sHJT+p99ZG6joH y9jTTuXCUmpJE099PKB0VVtb9OnBDXeFCl4IxoVn5fKdjIC004lVwVKpS4FN59XQUjGi dyvSR8prN94oddHaG0Y4mJWesPuLVZOHbQWbnjz8sAU4cDrmUXRACHCjn5uxo0lFXhqy OwnHVqqAYqwJD0kIgzxhAGnodYMx4YADZrYiTimkyVw5ApBRJ9oNUW7qnm5fOOS5CGE3 BNkg== X-Gm-Message-State: ALoCoQnowi8i77xTvdaoum3AjPwDrhvafKZoWlwmcsozsG2bLvI5qzpnfc/Q0zFKldLhSSWYzvZK X-Received: by 10.140.30.70 with SMTP id c64mr60191356qgc.13.1402611817995; Thu, 12 Jun 2014 15:23:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Thu, 12 Jun 2014 15:23:17 -0700 (PDT) In-Reply-To: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Jun 2014 00:23:17 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3N_c5qSaioLP-4lBDMtifenhNwQ Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 12 Jun 2014 22:23:41 -0000 2014-06-12 17:35 GMT+02:00 Olle E. Johansson : >> Well, not exactly IMHO. If you run NAPTR/SRV records then the SIP UA >> will try to contact "sip:myserver.com". After DNS NAPTR/SRV/A/AAAA >> resolution that will point to any hostname. That's not a problem. The >> certificate in those different servers must just contain >> "myserver.com". >> > Not according to the SIP Domain cert RFC, I=C3=B1aki. You need to check f= or > the SIP domain in the SIP URI in the SAN fields. Not at all: http://tools.ietf.org/html/rfc5922#section-7.1 ------------------ 2. If and only if the subjectAltName does not appear in the certificate, the implementation MAY examine the CN field of the certificate. If a valid DNS name is found there, the implementation MAY accept this value as a SIP domain identity. ------------------ ;) Of course, the problem is that if you have several servers for the same domain (so NAPTR/SRV is in use) then in-dialog requests follow the record-routing mechanism and thus each of those servers will set a RR like: Record-Route: server01.example.com and the SIP UA must send an in-dialog request to that URI (which becomes a Route header for in-dialog requests). Then the UA may have to open a new connection to the server (or reuse the previous one once it realizes that it is the same IP:port:transport than the initial request), and may need to, again, inspect the certificate provided by the server. In that case SubjectAltName is required since the server certificate must include both example.com and server01.example.com. So that is the real pain of SIP and TLS, and the reason for it to NEVER success (and it will never success because it is really badly designed, and even following the RFC line by line it becomes SO hard to make it work). --=20 I=C3=B1aki Baz Castillo From nobody Thu Jun 12 23:23: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 3EF4A1A0384 for ; Thu, 12 Jun 2014 23:23:40 -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 CT-aMOIlmQDw for ; Thu, 12 Jun 2014 23:23:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDA81A036C for ; Thu, 12 Jun 2014 23:23:37 -0700 (PDT) X-AuditID: c1b4fb2d-f79776d000001085-f8-539a98e71cc3 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.5E.04229.7E89A935; Fri, 13 Jun 2014 08:23:35 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.173]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Fri, 13 Jun 2014 08:23:34 +0200 From: Ivo Sedlacek To: Rifaat Shekh-Yusef , Christer Holmberg Thread-Topic: [sipcore] SIP OAuth: Information element to carry token Thread-Index: Ac+GXAtV4bffJBdGSQCga8JWstB7EP//5UaA//8AVuA= Date: Fri, 13 Jun 2014 06:23:34 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101126E788AESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rvf5jFnBBg1vNSx2vmhls/j6YxOb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxaut/1oLm+IrGfzMYGxifhHYxcnJICJhI fPj+gx3CFpO4cG89WxcjF4eQwFFGiTfHWxghnCWMEg/+/wSrYhPQk5i45QgriC0ikCIx+8R3 ZhCbWUBT4tHOvUwgtrCAi0TXr8VsEDWuEhtXLWeBsK0kviw6AhZnEVCV6J70EGgmBwevgK/E 4hvFELumMErcPXAFbD6nQKDE0i0XwWYyCshKXP3TywixS1zi1pP5TBBXC0gs2XOeGcIWlXj5 +B8ryEwJAUWJ5f1yEOX5EluO3wRbyysgKHFy5hOWCYyis5BMmoWkbBaSMoi4nsSzU7OgbG2J ZQtfM0PYuhKXHq5jRRZfwMi+ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMw3g5u+a27g3H1 a8dDjAIcjEo8vA+UZgULsSaWFVfmHmKU5mBREue9pFEdLCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoGxPu/0jwll9st0uXs/dr4rvvZ6geLz4k2Xq5SCi3ct16qXTp7ddSSg/5X4irgmpinr 67W//VuZ8XLWvJWbGX4dlH92MfMDhzLHrGmS/386sqzerMrLKVxcwhW6Q7P5bcqLvDdLzcMn PYvcZ3XWyjzC4fH/VS6NXgqb3a5d1pkfv2fxGT2G7XfXKbEUZyQaajEXFScCAEohK/CYAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/QZc-vdzuWRSNMFG5CTBqs4791fw Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 13 Jun 2014 06:23:40 -0000 --_000_39B5E4D390E9BD4890E2B31079006101126E788AESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, I share the same view as Christer. New authentication schemes should preferably extend / re-use the headers de= fined for authentication (i.e. WWW-Authenticate, Authorization, Authenticat= ion-Info, Proxy-Authenticate, Proxy-Authorization). This would enable usage of the OAuth method in any protocol which uses thos= e headers. This would enable usage of the OAuth method in (a) authentication with prox= y and (b) authentication with server. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Y= usef Sent: 12. =E8ervna 2014 18:58 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP OAuth: Information element to carry token Hi Christer, I tried to keep this proposal aligned with approach taken by RFC6749, but I= think that using Authorization header would be a valid option too. Is there any reason that you prefer it to be carried in the Authorization h= eader instead of the message body? Regards, Rifaat On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg > wrote: Hi, I was taking a look at draft-yusef-sipcore-sip-oauth-00. In section 4, I see that the OAuth token is carried in a message body. Is t= here a reason why one could not use the SIP Authorization header field? Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_39B5E4D390E9BD4890E2B31079006101126E788AESESSMB301erics_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

 

I share the same view as Ch= rister.

 

New authentication schemes = should preferably extend / re-use the headers defined for authentication (i= .e. WWW-Authenticate, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

 

This would enable usage of = the OAuth method in any protocol which uses those headers.

 

This would enable usage of = the OAuth method in (a) authentication with proxy and (b) authentication wi= th server.

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_discla= imer

From: sipcore = [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. =E8ervna 2014 18:58
To: Christer Holmberg
Cc: sipcore@ietf.org
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

 

Hi Christer,

 

I tried to keep this proposal aligned with approach = taken by RFC6749, but I think that using Authorization header would be a va= lid option too.

Is there any reason that you prefer it to be carried= in the Authorization header instead of the message body?

 

Regards,

 Rifaat

 

 

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

I was taking a look at draft-yusef-sipcore-sip-oauth-00= .

 

In section 4, I = see that the OAuth token is carried in a message body. Is there a reason wh= y one could not use  the SIP Authorization header field?

 

Regards,<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:black">

 

Christer


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

 

--_000_39B5E4D390E9BD4890E2B31079006101126E788AESESSMB301erics_-- From nobody Fri Jun 13 01:39: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 C217E1A0339 for ; Fri, 13 Jun 2014 01:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 glGnmr5hik-W for ; Fri, 13 Jun 2014 01:39:24 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8A85E1A021E for ; Fri, 13 Jun 2014 01:39:23 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id 2ABA493C2A2; Fri, 13 Jun 2014 08:38:37 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jun 2014 09:39:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/sV5JFX0Bqe7ZPow73CZrvTxCFhM Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 08:39:26 -0000 On 12 Jun 2014, at 23:23, I=F1aki Baz Castillo wrote: > 2014-06-12 17:35 GMT+02:00 Olle E. Johansson : >>> Well, not exactly IMHO. If you run NAPTR/SRV records then the SIP UA >>> will try to contact "sip:myserver.com". After DNS NAPTR/SRV/A/AAAA >>> resolution that will point to any hostname. That's not a problem. = The >>> certificate in those different servers must just contain >>> "myserver.com". >>>=20 >> Not according to the SIP Domain cert RFC, I=F1aki. You need to check = for >> the SIP domain in the SIP URI in the SAN fields. >=20 >=20 > Not at all: >=20 > http://tools.ietf.org/html/rfc5922#section-7.1 >=20 > ------------------ > 2. If and only if the subjectAltName does not appear in the > certificate, the implementation MAY examine the CN field of the > certificate. If a valid DNS name is found there, the > implementation MAY accept this value as a SIP domain identity. > ------------------ >=20 Yes, but you still map against the domain of the SIP URI, not the host name that is the result of SRV lookups. > ;) >=20 >=20 > Of course, the problem is that if you have several servers for the > same domain (so NAPTR/SRV is in use) then in-dialog requests follow > the record-routing mechanism and thus each of those servers will set a > RR like: >=20 > Record-Route: server01.example.com >=20 > and the SIP UA must send an in-dialog request to that URI (which > becomes a Route header for in-dialog requests). Then the UA may have > to open a new connection to the server (or reuse the previous one once > it realizes that it is the same IP:port:transport than the initial > request), and may need to, again, inspect the certificate provided by > the server. >=20 > In that case SubjectAltName is required since the server certificate > must include both example.com and server01.example.com. Record route adds a requirement for a SAN with the hostname, yes. That's why record-routing with IP addresses is not recommended for TLS. This also reminds me that we need to mention record-routes in our draft, so thank you for that comment. >=20 > So that is the real pain of SIP and TLS, and the reason for it to > NEVER success (and it will never success because it is really badly > designed, and even following the RFC line by line it becomes SO hard > to make it work). Well, it certainly works for Microsoft lync. I don't see them using the SIP domain certs with URI's, but both Lync and Exchange pushed the CAs to start selling certificates with SAN support. Which means that SAN certificates is now commercially available, certificates that can be used in DANE processing if one wants to use a CA cert and not anchor the cert in DNS/DNSsec alone. /O= From nobody Fri Jun 13 02:04: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 9B22D1A035B for ; Fri, 13 Jun 2014 02:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 50hiInFm6WpG for ; Fri, 13 Jun 2014 02:04:47 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB71F1A030E for ; Fri, 13 Jun 2014 02:04:46 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id w8so3042170qac.25 for ; Fri, 13 Jun 2014 02:04:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=iY6ARYF3VYRofvAZEW7h/+QaJKS34eNeNiGfI9E4HZg=; b=kDb99O+YUnqzMbnR3c2m+HwzmPm7OVtXZNiB7Mk0dJ6YizYljoyvXzhEHnhXf83coW Jf1Sf03JBDGccgbyHBvYQO3a1ZFaHpL5n0Vz6LSXfEagcqYKFo0LRZpaXtbBLFIrL5ft Fzz3pwurePcDH66mfpfg4XtYbe2hsBxElYEadZ354CUybYwq0ZQSMLfoFPrwQDznZ2DC csXGWmwdxMQ71ZeWIoPdo0U+D1ulL9HmF3u3TtW0DFjJdwcpFFrh8pWacLKVWwQQdcRc ZASpxWCqefa8LmzvMpxSrRIqje7llKJ+v5L0Gh0V3dNsTVTawJiQ1h0UrZB3zY9khf9s kn0Q== X-Gm-Message-State: ALoCoQmVOpzciXradgDv0dRiim9XYJCvngShaDD7VDH0ekxZ4vC6NZRi13cwom7SD/Btp60fapzb X-Received: by 10.140.30.70 with SMTP id c64mr1404124qgc.13.1402650286056; Fri, 13 Jun 2014 02:04:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Fri, 13 Jun 2014 02:04:25 -0700 (PDT) In-Reply-To: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Jun 2014 11:04:25 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/RhLZ-8s1lfIN-1RJlfdY8dGW1tg Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 09:04:48 -0000 2014-06-13 10:39 GMT+02:00 Olle E. Johansson : >>> Not according to the SIP Domain cert RFC, I=C3=B1aki. You need to check= for >>> the SIP domain in the SIP URI in the SAN fields. >> >> >> Not at all: >> >> http://tools.ietf.org/html/rfc5922#section-7.1 >> >> ------------------ >> 2. If and only if the subjectAltName does not appear in the >> certificate, the implementation MAY examine the CN field of the >> certificate. If a valid DNS name is found there, the >> implementation MAY accept this value as a SIP domain identity. >> ------------------ >> > Yes, but you still map against the domain of the SIP URI, not the > host name that is the result of SRV lookups. That is exactly what I said. - Alice must register to atlanta.com. - DNS NAPTR/SRV procedures select host01.atlanta.com DNS A record. - Alice establishes TLS connection with host01.atlanta.com. - The server MUST provide a certificate with SubjectAltName, DNS, or CN with value "atlanta.com". No problem, really. >> Of course, the problem is that if you have several servers for the >> same domain (so NAPTR/SRV is in use) then in-dialog requests follow >> the record-routing mechanism and thus each of those servers will set a >> RR like: >> >> Record-Route: server01.example.com >> >> and the SIP UA must send an in-dialog request to that URI (which >> becomes a Route header for in-dialog requests). Then the UA may have >> to open a new connection to the server (or reuse the previous one once >> it realizes that it is the same IP:port:transport than the initial >> request), and may need to, again, inspect the certificate provided by >> the server. > >> >> In that case SubjectAltName is required since the server certificate >> must include both example.com and server01.example.com. > Record route adds a requirement for a SAN with the hostname, yes. > That's why record-routing with IP addresses is not recommended for TLS. > > This also reminds me that we need to mention record-routes in our > draft, so thank you for that comment. In OverSIP proxy I added this configuration settings for fixing that proble= m: --------------------- record_route_hostname_tls_ipv4 When enabled, OverSIP writes the given domain/hostname in the Record-Route/Path headers when proxing a SIP request via TLS or WSS transport over IPv4 (instead of writing the listening IPv4 address). This is convenient when a peer open a new TLS/WSS connection to OverSIP for sending an in-dialog request so the peer can check whether the host part of the top Route header matches a domain in the certificate OverSIP provides to the peer during the TLS negotiation. This requirement is documented in RFC 5922 (=E2=80=9CDomain Certificates in SIP=E2=80=9D) section 7.5. --------------------- --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 13 02:21:01 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 AE5881A064C for ; Fri, 13 Jun 2014 02:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 Om0Q0PvwPVZK for ; Fri, 13 Jun 2014 02:20:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E91A03DB for ; Fri, 13 Jun 2014 02:20:58 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id 5608D93C2A1; Fri, 13 Jun 2014 09:20:12 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jun 2014 10:20:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> To: =?windows-1252?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/UQI41ZnHa9eGXjqs2c5O9rdk57E Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 09:21:00 -0000 On 13 Jun 2014, at 10:04, I=F1aki Baz Castillo wrote: > 2014-06-13 10:39 GMT+02:00 Olle E. Johansson : >>>> Not according to the SIP Domain cert RFC, I=F1aki. You need to = check for >>>> the SIP domain in the SIP URI in the SAN fields. >>>=20 >>>=20 >>> Not at all: >>>=20 >>> http://tools.ietf.org/html/rfc5922#section-7.1 >>>=20 >>> ------------------ >>> 2. If and only if the subjectAltName does not appear in the >>> certificate, the implementation MAY examine the CN field of the >>> certificate. If a valid DNS name is found there, the >>> implementation MAY accept this value as a SIP domain identity. >>> ------------------ >>>=20 >> Yes, but you still map against the domain of the SIP URI, not the >> host name that is the result of SRV lookups. >=20 > That is exactly what I said. >=20 > - Alice must register to atlanta.com. >=20 > - DNS NAPTR/SRV procedures select host01.atlanta.com DNS A record. >=20 > - Alice establishes TLS connection with host01.atlanta.com. >=20 > - The server MUST provide a certificate with SubjectAltName, DNS, or > CN with value "atlanta.com". >=20 > No problem, really. >=20 Then someone performs a hostile takeover of stockholm.com and all the certificates need to change when they migrate the domain to the = unified=20 communication platform of atlanta.com. With DANE we match the hostname in the SRV with the cert, so as long as you add domains and sign it with DNSsec, you don't have to reissue certificates. >=20 >=20 >=20 >>> Of course, the problem is that if you have several servers for the >>> same domain (so NAPTR/SRV is in use) then in-dialog requests follow >>> the record-routing mechanism and thus each of those servers will set = a >>> RR like: >>>=20 >>> Record-Route: server01.example.com >>>=20 >>> and the SIP UA must send an in-dialog request to that URI (which >>> becomes a Route header for in-dialog requests). Then the UA may have >>> to open a new connection to the server (or reuse the previous one = once >>> it realizes that it is the same IP:port:transport than the initial >>> request), and may need to, again, inspect the certificate provided = by >>> the server. >>=20 >>>=20 >>> In that case SubjectAltName is required since the server certificate >>> must include both example.com and server01.example.com. >> Record route adds a requirement for a SAN with the hostname, yes. >> That's why record-routing with IP addresses is not recommended for = TLS. >>=20 >> This also reminds me that we need to mention record-routes in our >> draft, so thank you for that comment. >=20 > In OverSIP proxy I added this configuration settings for fixing that = problem: >=20 >=20 > --------------------- > record_route_hostname_tls_ipv4 >=20 > When enabled, OverSIP writes the given domain/hostname in the > Record-Route/Path headers when proxing a SIP request via TLS or WSS > transport over IPv4 (instead of writing the listening IPv4 address). > This is convenient when a peer open a new TLS/WSS connection to > OverSIP for sending an in-dialog request so the peer can check whether > the host part of the top Route header matches a domain in the > certificate OverSIP provides to the peer during the TLS negotiation. > This requirement is documented in RFC 5922 (=93Domain Certificates in > SIP=94) section 7.5. > --------------------- Nice! /O= From nobody Fri Jun 13 02:23: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 562B81A03F8 for ; Fri, 13 Jun 2014 02:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 QJKOIHNv3buZ for ; Fri, 13 Jun 2014 02:23:19 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7961A03DB for ; Fri, 13 Jun 2014 02:23:19 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so3906204qcy.1 for ; Fri, 13 Jun 2014 02:23:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=f6HnKZWc10L+IwxySM5FFgNJev/7kNHENVpUjK30w5M=; b=YQusx/vQJUh8B+Mrhbq91UMjAuo5XXi+ycbEwKWrSFBbwoLWmaMgGTeWWBtFdA362R At46elU9baE1+VC0qHfGp3Fx1Z+5BHUZDXySc9AvI+OPOlmUxLnP3oe9QQP6pVNyrJ0o yyNYSOMXOv19YWv02Kg/Txde0tqF1NS+yVnaIVnW3SS2Gsl6cdYNpyf6AeEa0M6DeJRM lXKsNZ0NnCCeAhXOsfMHLIelpg7uLcHfytMHdzYNS+FVDMO9ccO7sX8QVPuHgLToEsK0 lq72e7vRYU67gHvBLbfTwL00xNIuBRjSMP1OUAYkmNjzCmrz4d7qd7Ci1xZK1LmIXOVw khJw== X-Gm-Message-State: ALoCoQkt/2AlpWXqccFxrYKRMxWu6/2UBYrjoDQGrRZ4rvry3CsnGdSdSAOKAe3ROkDqfMNLcmD4 X-Received: by 10.224.162.212 with SMTP id w20mr1713659qax.50.1402651398253; Fri, 13 Jun 2014 02:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Fri, 13 Jun 2014 02:22:57 -0700 (PDT) In-Reply-To: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Jun 2014 11:22:57 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HT044L-dCW1DW72Wz2oxaLnHiSg Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 09:23:20 -0000 2014-06-13 11:20 GMT+02:00 Olle E. Johansson : >> That is exactly what I said. >> >> - Alice must register to atlanta.com. >> >> - DNS NAPTR/SRV procedures select host01.atlanta.com DNS A record. >> >> - Alice establishes TLS connection with host01.atlanta.com. >> >> - The server MUST provide a certificate with SubjectAltName, DNS, or >> CN with value "atlanta.com". >> >> No problem, really. >> > Then someone performs a hostile takeover of stockholm.com and all > the certificates need to change when they migrate the domain to the unifi= ed > communication platform of atlanta.com. With DANE we match the hostname > in the SRV with the cert, so as long as you add domains and sign > it with DNSsec, you don't have to reissue certificates. May you please repeat my example "flow" above but now with DANE? --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 13 02:38: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 C86561A038C for ; Fri, 13 Jun 2014 02:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 svvhS99DqGbQ for ; Fri, 13 Jun 2014 02:38:52 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 589AD1A0140 for ; Fri, 13 Jun 2014 02:38:52 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id A5AC993C2A1; Fri, 13 Jun 2014 09:38:06 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jun 2014 10:38:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/FnMdmND1LcB4UNvSCN2TtELhLs4 Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 09:38:53 -0000 On 13 Jun 2014, at 10:22, I=F1aki Baz Castillo wrote: > 2014-06-13 11:20 GMT+02:00 Olle E. Johansson : >>> That is exactly what I said. >>>=20 >>> - Alice must register to atlanta.com. >>>=20 >>> - DNS NAPTR/SRV procedures select host01.atlanta.com DNS A record. >>>=20 >>> - Alice establishes TLS connection with host01.atlanta.com. >>>=20 >>> - The server MUST provide a certificate with SubjectAltName, DNS, or >>> CN with value "atlanta.com". >>>=20 >>> No problem, really. >>>=20 >> Then someone performs a hostile takeover of stockholm.com and all >> the certificates need to change when they migrate the domain to the = unified >> communication platform of atlanta.com. With DANE we match the = hostname >> in the SRV with the cert, so as long as you add domains and sign >> it with DNSsec, you don't have to reissue certificates. >=20 >=20 > May you please repeat my example "flow" above but now with DANE? Alice calls to aveiro.com Alice's UA use DNS, validated with DNSsec and ends up with a hostname = froggy.edvina.net The whole query is verified as a secure response. froggy.edvina.net has a certificate with CN being froggy.edvina.net aveiro.com makes a hostile takeover of bilbao.com Bilbao.com is merged into the same unified realtime supercommunication = platform as aveiro.com Bob calls bilbao.com and ends up with hostname froggy.edvina.net=20 The whole DNS query is verified using DNSsec. froggy.edvina.net has a certificate with CN being froggy.edvina.net Now, there are at least two options for validating the certificate = froggy.edvina.net. One is that edvina.net says that "froggy.edvina.net" only use the Fluffy CA and = nothing else. Now if Alice and Bob gets a certifcate from the Castillo CA, something = is wrong and their phones doees not connect. The other option is that there's a fingerprint of the certificate in a = TLSA record. Now, they validate the certificate given by the server with the = fingerprint that they got in a secure way using DNS/DNSsec. No PKI structure other = than the DNSsec is used. At some point we may have bare keys used and no PKIX/X.509 certs at all. I may have missed something here, but keep asking questions! Cheers, /O= From nobody Fri Jun 13 03:55:12 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 6E6E91B2822 for ; Fri, 13 Jun 2014 03:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 dQLJjbGWel2h for ; Fri, 13 Jun 2014 03:55:09 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D0C1A04AC for ; Fri, 13 Jun 2014 03:55:09 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so3198182qac.21 for ; Fri, 13 Jun 2014 03:55:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Cb+qKsML3KjFTw2DI9RGWkSrg9PEWBVAi8ORWcvO0Wo=; b=EjJTYqRz1tYX8g63HyrSEmbFMljO4RstCZ0ixjVQC6fpv9eTSKD7Td4SBFVMVhn4lZ 4SFYxpLZ4ubut86/LM5K+sgkUBpOQ89o+cR5Aoe6wEJ6CimpUGgy12r08BzpN6U8n8iF WtmnHIm9HbH4IbdeXxRtUoSufrF1P3xpoH+NbpWw08C/o6rXi5PVlXPksEl47jCDuJHI KUE0mBX1c6ensEIlFrNvU/C+xo/Ps9GTtyMf9EcmISSsaI9fBWql65hyFBPi3M/Td85g ADaAckJGUgISsTpn9G857tcC2nEJZ+XPBEp82JjVzbekpJ4uRaP5Dt3eiLdZKS+YNXD9 zvuQ== X-Gm-Message-State: ALoCoQlT2htRjrxfbhMoRqQhIKg/urxlwEjEwHpbcMRRAl5kyE2Kz5pdtpVsaxYPBi1drwN7+S+s X-Received: by 10.229.93.133 with SMTP id v5mr2315857qcm.1.1402656908406; Fri, 13 Jun 2014 03:55:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Fri, 13 Jun 2014 03:54:48 -0700 (PDT) In-Reply-To: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Jun 2014 12:54:48 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/z0_3o86YiATvlIm6VgpVruJbmE4 Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 10:55:11 -0000 2014-06-13 11:38 GMT+02:00 Olle E. Johansson : > Alice calls to aveiro.com > > Alice's UA use DNS, validated with DNSsec and ends up with a hostname fro= ggy.edvina.net > The whole query is verified as a secure response. > > froggy.edvina.net has a certificate with CN being froggy.edvina.net > > aveiro.com makes a hostile takeover of bilbao.com > > Bilbao.com is merged into the same unified realtime supercommunication pl= atform as aveiro.com > > Bob calls bilbao.com and ends up with hostname froggy.edvina.net > The whole DNS query is verified using DNSsec. > > froggy.edvina.net has a certificate with CN being froggy.edvina.net > > Now, there are at least two options for validating the certificate froggy= .edvina.net. One is that > edvina.net says that "froggy.edvina.net" only use the Fluffy CA and nothi= ng else. > Now if Alice and Bob gets a certifcate from the Castillo CA, something is= wrong and > their phones doees not connect. > > The other option is that there's a fingerprint of the certificate in a TL= SA record. > Now, they validate the certificate given by the server with the fingerpri= nt > that they got in a secure way using DNS/DNSsec. No PKI structure other th= an > the DNSsec is used. > > At some point we may have bare keys used and no PKIX/X.509 certs at all. > > I may have missed something here, but keep asking questions! This is great. But it behaves different than the current SIP-cert procedures (as the device checks the resulting hostname after DNS procedures rather than the initial domain before NAPTR/SRV). Well, IMHO it is MUCH better in this way, but it is not consistent with how SIP-cert works. Both SIP-cert and DANE perform two steps: 1) Get a certificate. 2) Decide which domain must be used to check the received certificate. 3) Check the certificate. Step 1 is the same for both. Step 2 is different (SIP-cert uses the domain before DNS procedures while DANE uses the domain after DNS procedures). Step 3 is obviously different (right). I wonder about step 2. I would be happy if another spec changes that also for SIP-cert procedures. --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 13 04:06: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 4BDFB1B28A9 for ; Fri, 13 Jun 2014 04:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 vcMJ2h39AEGD for ; Fri, 13 Jun 2014 04:06:17 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 7122C1B283C for ; Fri, 13 Jun 2014 04:06:16 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id 01A7293C2A1; Fri, 13 Jun 2014 11:05:30 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jun 2014 12:06:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/1or7oyOowSEeZg5jVW-iK65HG_E Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 11:06:19 -0000 On 13 Jun 2014, at 11:54, I=F1aki Baz Castillo wrote: > 2014-06-13 11:38 GMT+02:00 Olle E. Johansson : >> Alice calls to aveiro.com >>=20 >> Alice's UA use DNS, validated with DNSsec and ends up with a hostname = froggy.edvina.net >> The whole query is verified as a secure response. >>=20 >> froggy.edvina.net has a certificate with CN being froggy.edvina.net >>=20 >> aveiro.com makes a hostile takeover of bilbao.com >>=20 >> Bilbao.com is merged into the same unified realtime = supercommunication platform as aveiro.com >>=20 >> Bob calls bilbao.com and ends up with hostname froggy.edvina.net >> The whole DNS query is verified using DNSsec. >>=20 >> froggy.edvina.net has a certificate with CN being froggy.edvina.net >>=20 >> Now, there are at least two options for validating the certificate = froggy.edvina.net. One is that >> edvina.net says that "froggy.edvina.net" only use the Fluffy CA and = nothing else. >> Now if Alice and Bob gets a certifcate from the Castillo CA, = something is wrong and >> their phones doees not connect. >>=20 >> The other option is that there's a fingerprint of the certificate in = a TLSA record. >> Now, they validate the certificate given by the server with the = fingerprint >> that they got in a secure way using DNS/DNSsec. No PKI structure = other than >> the DNSsec is used. >>=20 >> At some point we may have bare keys used and no PKIX/X.509 certs at = all. >>=20 >> I may have missed something here, but keep asking questions! >=20 > This is great. But it behaves different than the current SIP-cert > procedures (as the device checks the resulting hostname after DNS > procedures rather than the initial domain before NAPTR/SRV). >=20 > Well, IMHO it is MUCH better in this way, but it is not consistent > with how SIP-cert works. Which we point out in the draft... >=20 > Both SIP-cert and DANE perform two steps: >=20 > 1) Get a certificate. >=20 > 2) Decide which domain must be used to check the received certificate. s/domain/name/ >=20 > 3) Check the certificate. >=20 > Step 1 is the same for both. > Step 2 is different (SIP-cert uses the domain before DNS procedures > while DANE uses the domain after DNS procedures). > Step 3 is obviously different (right). >=20 > I wonder about step 2. I would be happy if another spec changes that > also for SIP-cert procedures. This is the spec... :-) /O= From nobody Fri Jun 13 04:08: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 699BC1B284A for ; Fri, 13 Jun 2014 04:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 yOS17ckRnWZw for ; Fri, 13 Jun 2014 04:08:34 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E8B1A0463 for ; Fri, 13 Jun 2014 04:08:34 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so3172210qac.4 for ; Fri, 13 Jun 2014 04:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=QjKxCaBzitfv54NQodKId3iYJbcwyx9UOhGz3B+5UNs=; b=Vr6+tiWFQMM5PjDiYQRgPbHQw6Hbu8SB500rwXFa8BHKdsE0iMnUmZdcR+x63SVpjc sOrEZbQV7cFbbEVa9DkiL2Kfo1dbJsIriNt9pq9o8+w+lc2GL3Fz191gpEm9ARKqS/oa du3RUq8um0izIgIZu/eTNoAIw7kdkeCRN0yJAKROyqsHGYbrJn7YT+/eyJgmSr7P06dB +Pv+D+jQhgYoAS1kN4fyZbwhAe+F98jntUHJVjdDfwmMI+7+O5bps/L87mIaW+Bt3qnJ V5MSP6aWa5QAoZZ9011IpMkcmBBUtihnmx3OUJKjRmNwfVI1H9QEMTsOmFvHP69GadZ2 YgSQ== X-Gm-Message-State: ALoCoQlAv/VtmCT+wu+dKXYnoO0V2UIK90jyArf+xsYCnHjuV+58lx5Gk5S8Ibg9IzAe8tlSBth0 X-Received: by 10.229.97.71 with SMTP id k7mr2468203qcn.4.1402657713352; Fri, 13 Jun 2014 04:08:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Fri, 13 Jun 2014 04:08:13 -0700 (PDT) In-Reply-To: <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Jun 2014 13:08:13 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/JYSOmoSS1j3hENiGAi2VJvKKdj8 Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 11:08:44 -0000 2014-06-13 13:06 GMT+02:00 Olle E. Johansson : >> I wonder about step 2. I would be happy if another spec changes that >> also for SIP-cert procedures. > > This is the spec... :-) But just for DANE and not for "normal" SIP-cert, right? or do I miss someth= ing? --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 13 04:14:23 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 0A7B71B279B for ; Fri, 13 Jun 2014 04:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 frcCDm4pULUq for ; Fri, 13 Jun 2014 04:14:20 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 608ED1A0463 for ; Fri, 13 Jun 2014 04:14:19 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id 4A39893C2A1; Fri, 13 Jun 2014 11:13:34 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jun 2014 12:14:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <943E1DBE-7A46-42F1-92CB-651CB39BAB14@edvina.net> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4b-DiRoPY-qiuhqf07Y63em7TOw Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 11:14:21 -0000 On 13 Jun 2014, at 12:08, I=F1aki Baz Castillo wrote: > 2014-06-13 13:06 GMT+02:00 Olle E. Johansson : >>> I wonder about step 2. I would be happy if another spec changes that >>> also for SIP-cert procedures. >>=20 >> This is the spec... :-) >=20 > But just for DANE and not for "normal" SIP-cert, right? or do I miss = something? No, but the world needs to move to DANE and forget the rest... SIP domain certs make sense when you can't trust the DNS imho. (At least in my dreams) :-) /O= From nobody Fri Jun 13 04:19: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 7A44B1A04C8 for ; Fri, 13 Jun 2014 04:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 hP70OOMdLE0V for ; Fri, 13 Jun 2014 04:19:07 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA1A1A0463 for ; Fri, 13 Jun 2014 04:19:06 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so4064122qcy.1 for ; Fri, 13 Jun 2014 04:19: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hob563oDo6DtXV1JiNaVj9GFrr8hnCvScS659hf30iE=; b=RqazeBrHTA15b7PyKnVoGJnV2vIpBjPlFD9InRhT/4lYTbf454r2FCKV2KzG4qnNxJ AVyeDD1GI9EH2ft6uGiuAq2to7kSRFj+y+EdY57j9g12AueunQBSwhGe0NuIDu3FyKyM zvz0fio8zrOGZRDejePXg/XAQFt003slI7B/+rzSzd43vjcIMT0UnaOBQVlSV0HgQ8O7 N7eu1BykMBBK1EJWt56sDMAZA1f0KmUfXaLnLAb8wQGy6OZPeMxjfRAFYwoWHNPfajp3 e+9FZ0CC2attdEPj6ulaJ6U/8MrkU6f1aSF+GUEnMtq49QfQkF1wvO0tR858Bnz3Z9cz AhEQ== X-Gm-Message-State: ALoCoQlpK0Heis164kFAqrbz9p1mBsVladSUpD05fQXp+t24YxlkISHBgHBj7JnmIlZDHCD6jlLW X-Received: by 10.224.79.198 with SMTP id q6mr2301263qak.99.1402658345967; Fri, 13 Jun 2014 04:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Fri, 13 Jun 2014 04:18:45 -0700 (PDT) In-Reply-To: <943E1DBE-7A46-42F1-92CB-651CB39BAB14@edvina.net> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> <943E1DBE-7A46-42F1-92CB-651CB39BAB14@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Jun 2014 13:18:45 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9u-wGbez3d7ruYBBhy842PnfBzs Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 11:19:07 -0000 2014-06-13 13:14 GMT+02:00 Olle E. Johansson : > No, but the world needs to move to DANE and forget the rest... Please add "This document deprecates and looks down RFC 5922". --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 13 04:20:51 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 1586E1B28F9 for ; Fri, 13 Jun 2014 04:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 HHlfoKnfzIGc for ; Fri, 13 Jun 2014 04:20:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 38C021B28ED for ; Fri, 13 Jun 2014 04:20:45 -0700 (PDT) Received: from [192.168.6.145] (unknown [62.28.178.18]) by smtp7.webway.se (Postfix) with ESMTPA id 6E7FB93C2A1; Fri, 13 Jun 2014 11:20:00 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jun 2014 12:20:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <249C74EB-A33D-49A0-9E96-68F04E6DBB25@edvina.net> References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> <943E1DBE-7A46-42F1-92CB-651CB39BAB14@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/jCr7x3gw6KxWjyPv7sua9vu69Lc Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 11:20:48 -0000 On 13 Jun 2014, at 12:18, I=F1aki Baz Castillo wrote: > 2014-06-13 13:14 GMT+02:00 Olle E. Johansson : >> No, but the world needs to move to DANE and forget the rest... >=20 > Please add "This document deprecates and looks down RFC 5922". Then we're updating RFC 3261 again and I will get the wrath of Cullen = over me ;-) There's a world without DNSsec out there and will be for a long time, = unfortunately. /O= From nobody Fri Jun 13 05:18:12 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 F2AD51A04CA for ; Fri, 13 Jun 2014 05:18:08 -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 M8MgBJDJXkQw for ; Fri, 13 Jun 2014 05:18:07 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97661B2849 for ; Fri, 13 Jun 2014 05:18:06 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so1476376igd.1 for ; Fri, 13 Jun 2014 05:18: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 :cc:content-type; bh=zusYHCPwXB9ju8SJeG++FhNoLSC1wMRde9MDwVI3mIs=; b=z7NIh4Dc97Q0PsAmcMll21RpF6w4uqjxcO03+8iMfk8ZG5GiUamRVkiAqLK3RBAHNv BUpIS50o+nGXx3P336Kd8t1LJN/WX4BgbvLQp3dKgogOS7SNiLB35la6S3uIVpNC5DDK G5YK9aDeZSKRU5olTGlmQrabX7oSWa2zYuL3Ta5xhQCfzBsqxckDLl0czw6/xVrd94t4 cd6e4PMdmIjezy27GkZtXHapDq2DXRm3HbF8NBO48462ty6S1ZQiayTDY7MBNsW0+ge1 krAZL2cmhhOuoK1vEWGwj41rW7s2BH7JJwA7ujo2bepaZ0bbW5Fm8if+Dt1RsMga9OZS qfbQ== MIME-Version: 1.0 X-Received: by 10.42.120.15 with SMTP id d15mr2878388icr.35.1402661886176; Fri, 13 Jun 2014 05:18:06 -0700 (PDT) Received: by 10.50.114.97 with HTTP; Fri, 13 Jun 2014 05:18:06 -0700 (PDT) In-Reply-To: <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> Date: Fri, 13 Jun 2014 08:18:06 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=90e6ba613c3a77339904fbb6ab77 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kcRSso-5ktrhdUZq3tbemaD3qV4 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 13 Jun 2014 12:18:09 -0000 --90e6ba613c3a77339904fbb6ab77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am fine with this; I will make the change in the next version of the draft. Regards, Rifaat On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek wrote: > Hello, > > > > I share the same view as Christer. > > > > New authentication schemes should preferably extend / re-use the headers > defined for authentication (i.e. WWW-Authenticate, Authorization, > Authentication-Info, Proxy-Authenticate, Proxy-Authorization). > > > > This would enable usage of the OAuth method in any protocol which uses > those headers. > > > > This would enable usage of the OAuth method in (a) authentication with > proxy and (b) authentication with server. > > > > Kind regards > > > > Ivo Sedlacek > > > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer > > *From:* sipcore [mailto:sipcore-bounces@ietf.org > ] *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* 12. =C4=8Dervna 2014 18:58 > *To:* Christer Holmberg > *Cc:* sipcore@ietf.org > *Subject:* Re: [sipcore] SIP OAuth: Information element to carry token > > > > Hi Christer, > > > > I tried to keep this proposal aligned with approach taken by RFC6749, but > I think that using Authorization header would be a valid option too. > > Is there any reason that you prefer it to be carried in the Authorization > header instead of the message body? > > > > Regards, > > Rifaat > > > > > > On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > I was taking a look at draft-yusef-sipcore-sip-oauth-00. > > > > In section 4, I see that the OAuth token is carried in a message body. Is > there a reason why one could not use the SIP Authorization header field? > > > > Regards, > > > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --90e6ba613c3a77339904fbb6ab77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am fine with this; I will make the change in the next ve= rsion of the draft.

Regards,
=C2=A0Rifaat



On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <ivo.sedlacek@ericss= on.com> wrote:

Hello,=

=C2=A0=

I share the same view as Ch= rister.

=C2=A0=

New authentication schemes = should preferably extend / re-use the headers defined for authentication (i= .e. WWW-Authenticate, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

=C2=A0=

This would enable usage of = the OAuth method in any protocol which uses those headers.

=C2=A0=

This would enable usage of = the OAuth method in (a) authentication with proxy and (b) authentication wi= th server.

=C2=A0=

Kind regards<= /span>

=C2=A0=

Ivo Sedlacek

=C2=A0=

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsso= n.com/email_disclaimer

From: sipcore = [mailto:sipco= re-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. =C4=8Dervna 2014 18:58
To: Christer Holmberg
Cc: sipcore@ie= tf.org
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

=C2=A0

Hi Christer,

=C2=A0

I tried to keep this proposal aligned with approach = taken by RFC6749, but I think that using Authorization header would be a va= lid option too.

Is there any reason that you prefer it to be carried= in the Authorization header instead of the message body?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0<= /p>

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0<= /p>

I was taking a look at draft-yusef-sipcore-sip-oauth-00= .

=C2=A0<= /p>

In section 4, I = see that the OAuth token is carried in a message body. Is there a reason wh= y=C2=A0one could not use=C2=A0 the SIP Authorization header field?

=C2=A0<= /p>

Regards,<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:black">

=C2=A0

Christer


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

=C2=A0


--90e6ba613c3a77339904fbb6ab77-- From nobody Fri Jun 13 07:46: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 6F4B71B2913 for ; Fri, 13 Jun 2014 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, 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 6qvxxeDdhcR4 for ; Fri, 13 Jun 2014 07:46:14 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C811A009A for ; Fri, 13 Jun 2014 07:46:13 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id A32B11DDDB; Fri, 13 Jun 2014 14:46:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1402670771; bh=bJlh1+ZQQbTpUwbrVQmY8ZmsBiHvIGmwIrPwJAX1+ZY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JJy6vLPGTUupBTU8E+dsEWUWMadyG0Ti3IjHREM8BzPGxig/aAvqv5Kt5cgba/8tk H8hSiSgrAsPg77/NzNC0rDQND8BIRBEjN/3CZs1Dkx4Nwd0KmQcA75MuSu/Y6Fw0vL xMMlc/udHEtMWbaEeDDshFNuWbo8khAo7dGRuki8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8B7E26001E; Fri, 13 Jun 2014 14:42:19 +0000 (UTC) From: James Cloos To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo In-Reply-To: (=?iso-8859-1?Q?=22I=F1aki?= Baz Castillo"'s message of "Fri, 13 Jun 2014 12:54:48 +0200") References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 13 Jun 2014 10:42:19 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:140613:ibc@aliax.net::oPb1HvijNlDNywCp:000V3eqq X-Hashcash: 1:30:140613:oej@edvina.net::rJBpDS0etu08LxaZ:00hovX1 X-Hashcash: 1:30:140613:sipcore@ietf.org::E+RUHzWj+cFwTyMK:4l2dO Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/wm6rU0IpsIbE3BUTvFUhWpk5gN4 Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 14:46:15 -0000 >>>>> "IBC" == I�aki Baz Castillo writes: IBC> This is great. But it behaves different than the current SIP-cert IBC> procedures (as the device checks the resulting hostname after DNS IBC> procedures rather than the initial domain before NAPTR/SRV). The current draft for dane for srv permits either name to be in the cert sent by the server, for backwards compatibility with the non-dane flow. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jun 13 07:52: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 74B491A028D for ; Fri, 13 Jun 2014 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 1aWMv-oH26B5 for ; Fri, 13 Jun 2014 07:52:29 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE9A1B27DF for ; Fri, 13 Jun 2014 07:52:29 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id hw13so2479117qab.6 for ; Fri, 13 Jun 2014 07:52:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=9FvHJQMoG+Mj833UL2eRYopzJyftaGpZMJDpnm9D3ew=; b=hzkVyNIGzPlYPEch4cP9OOWsJJ7ZW0WQsDQ+mwo1+cvYdAGfvIuaYSzCgbYsX2ENIF ln9astS/JbD5D8DmK99JNjXDmNXxpo0MeG09XisEzPc04Dr6ZvP/X1plEq7+/GA1Bn/6 mv+FxY8IT9PzIhKpYtN8dIPoV2FayQdKM/uqO3S2UZZy1jHkUOyv9ThZq47o1BLXWic4 x+yeY37DfHHu0eDlWHiQpeVy1q3l+bfWIzZQl8+7NovQcUzJY0H8SbSDUP3y7BoWxU2R Kn+lcLRqLtBX2Obd5RqhhXq6SVSIPlv6a+GPM6MucxkyiypsrtrLIZ+5CXNzNZ6Y1Y8t +51w== X-Gm-Message-State: ALoCoQlZbbI71RAZUqrTHNWfOmX5EIdgMnFE2HesGtXkW32SUBQyy9weVlXiZPwQEjFoak/jKfyn X-Received: by 10.224.79.198 with SMTP id q6mr3896336qak.99.1402671148344; Fri, 13 Jun 2014 07:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Fri, 13 Jun 2014 07:52:08 -0700 (PDT) In-Reply-To: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Jun 2014 16:52:08 +0200 Message-ID: To: James Cloos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/poJt3KSho2zSfep5kbWGjVzkA5A Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 14:52:31 -0000 2014-06-13 16:42 GMT+02:00 James Cloos : > IBC> This is great. But it behaves different than the current SIP-cert > IBC> procedures (as the device checks the resulting hostname after DNS > IBC> procedures rather than the initial domain before NAPTR/SRV). > > The current draft for dane for srv permits either name to be in the cert > sent by the server, for backwards compatibility with the non-dane flow. Cool then :) --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 13 08:51:31 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 8E01A1B2966 for ; Fri, 13 Jun 2014 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 DfvaxNfiUfP3 for ; Fri, 13 Jun 2014 08:51:26 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DACC1B2949 for ; Fri, 13 Jun 2014 08:51:26 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5DFoU6M020228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jun 2014 10:50:30 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5DFoTX6024856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jun 2014 10:50:29 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5DFoRlC029905; Fri, 13 Jun 2014 10:50:28 -0500 (CDT) Message-ID: <539B1E52.4030505@bell-labs.com> Date: Fri, 13 Jun 2014 10:52:50 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Olle E. Johansson" References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/qM2LbF0qoqIWzd5--O84Qw7JM14 Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 15:51:28 -0000 On 06/12/2014 05:23 PM, Iñaki Baz Castillo wrote: > Of course, the problem is that if you have several servers for the > same domain (so NAPTR/SRV is in use) then in-dialog requests follow > the record-routing mechanism and thus each of those servers will set a > RR like: > > Record-Route: server01.example.com > > and the SIP UA must send an in-dialog request to that URI (which > becomes a Route header for in-dialog requests). Then the UA may have > to open a new connection to the server (or reuse the previous one once > it realizes that it is the same IP:port:transport than the initial > request), and may need to, again, inspect the certificate provided by > the server. Exactly so. We grappled with all these issues back in 2006 or so when we were doing the work on the precursor to rfc5922. See [1]. [1] http://www.ietf.org/proceedings/67/slides/sip-6.pdf Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri Jun 13 09:48: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 D98AF1B27DF for ; Fri, 13 Jun 2014 09:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.277 X-Spam-Level: X-Spam-Status: No, score=-100.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 ADkUTKFR-LqZ for ; Fri, 13 Jun 2014 09:48:21 -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 B92A61B27AE for ; Fri, 13 Jun 2014 09:48:20 -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 s5DGkTwH024977; Fri, 13 Jun 2014 12:48:16 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1mg40c83pe-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jun 2014 12:48:15 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.116]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 12:48:15 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef , Ivo Sedlacek Thread-Topic: [sipcore] SIP OAuth: Information element to carry token Thread-Index: Ac+GXAtV4bffJBdGSQCga8JWstB7EAAJO3CAABwjqwAADGHGAP//1gQA Date: Fri, 13 Jun 2014 16:48:14 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.129.130] Content-Type: multipart/alternative; boundary="_000_CFC074CA11A3B5jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7468 signatures=670466 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=9.13158437754191e-14 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-1406130185 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/hSnzwXHH5EiDcr4FR9jMjYxmXEU Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 13 Jun 2014 16:48:24 -0000 --_000_CFC074CA11A3B5jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Well, the Authorization header field is defined in RFC2617, and the base SI= P specification instructs implementers to use its syntax. In other words, t= hese headers don't belong to us. The syntax and semantics of OAuth is nothi= ng like them. I don't think it's reasonable for us to just overload the syn= tax and semantics of the HTTP authentication system in this way for SIP. N= or is it that case that by doing so in SIP, we will allow "any protocol tha= t uses these headers" to use OAuth - that's exactly backwards. What we'd be= doing is creating fragmentation and confusion. Our OAuth usage should be aligned with HTTP's usage, that is, with RFC6749.= If we want something different, I think we need to talk to them about it. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Friday, June 13, 2014 at 5:18 AM To: Ivo Sedlacek > Cc: "sipcore@ietf.org" > Subject: Re: [sipcore] SIP OAuth: Information element to carry token I am fine with this; I will make the change in the next version of the draf= t. Regards, Rifaat On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek > wrote: Hello, I share the same view as Christer. New authentication schemes should preferably extend / re-use the headers de= fined for authentication (i.e. WWW-Authenticate, Authorization, Authenticat= ion-Info, Proxy-Authenticate, Proxy-Authorization). This would enable usage of the OAuth method in any protocol which uses thos= e headers. This would enable usage of the OAuth method in (a) authentication with prox= y and (b) authentication with server. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Y= usef Sent: 12. =E8ervna 2014 18:58 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP OAuth: Information element to carry token Hi Christer, I tried to keep this proposal aligned with approach taken by RFC6749, but I= think that using Authorization header would be a valid option too. Is there any reason that you prefer it to be carried in the Authorization h= eader instead of the message body? Regards, Rifaat On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg > wrote: Hi, I was taking a look at draft-yusef-sipcore-sip-oauth-00. In section 4, I see that the OAuth token is carried in a message body. Is t= here a reason why one could not use the SIP Authorization header field? Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_CFC074CA11A3B5jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable

Well, the Authorization header field is defined in RFC2617, and the ba= se SIP specification instructs implementers to use its syntax. In other wor= ds, these headers don't belong to us. The syntax and semantics of OAuth is = nothing like them. I don't think it's reasonable for us to just overload the syntax and semantics of the HT= TP authentication system in this way for SIP.  Nor is it that case tha= t by doing so in SIP, we will allow "any protocol that uses these head= ers" to use OAuth - that's exactly backwards. What we'd be doing is creating fragmentation and confusion. 

Our OAuth usage should be aligned with HTTP's usage, that is, with RFC= 6749. If we want something different, I think we need to talk to them about= it.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Friday, June 13, 2014 at 5:18= AM
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] SIP OAuth: I= nformation element to carry token

I am fine with this; I will make the change in the next ve= rsion of the draft.

Regards,
 Rifaat



On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <ivo.sedl= acek@ericsson.com> wrote:

Hello,

 

I share the same view as Christer.=

 

New authentication schemes should pre= ferably extend / re-use the headers defined for authentication (i.e. WWW-Au= thenticate, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

 

This would enable usage of the OAuth = method in any protocol which uses those headers.

 

This would enable usage of the OAuth = method in (a) authentication with proxy and (b) authentication with server.=

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We = only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. =E8ervna 2014 18:58
To: Christer Holmberg
Cc: sipcore@ie= tf.org
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

 

Hi Christer,

 

I tried to keep this proposal aligned with approach = taken by RFC6749, but I think that using Authorization header would be a va= lid option too.

Is there any reason that you prefer it to be carried= in the Authorization header instead of the message body?

 

Regards,

 Rifaat

 

 <= /p>

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

I was taking a look at draft-yusef-sipcore-sip-oauth-00.

 

In section 4, I see that the OAuth = token is carried in a message body. Is there a reason why one could no= t use  the SIP Authorization header field?

 

Regards,<= /span>

 

Christer


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

 


 --_000_CFC074CA11A3B5jonpetersonneustarbiz_-- From nobody Fri Jun 13 10:31:51 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 7964C1B27BC for ; Fri, 13 Jun 2014 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.967 X-Spam-Level: X-Spam-Status: No, score=-100.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, 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 ulCOcDqHpOi5 for ; Fri, 13 Jun 2014 10:31: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 853441B293F for ; Fri, 13 Jun 2014 10:31: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 s5DHM1df010996; Fri, 13 Jun 2014 13:31:43 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1mfxbu0huy-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jun 2014 13:31:43 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 13:31:42 -0400 From: "Peterson, Jon" To: Paul Kyzivat , Richard Barnes , "Cullen Jennings" , Robert Sparks Thread-Topic: [sipcore] Proceeding with dane-sip Thread-Index: AQHPhafXtDpL1ofq50++EDcMAgfvwZtsixQAgAAHNwCAAPLjgIAAUBsAgAFHrIA= Date: Fri, 13 Jun 2014 17:31:41 +0000 Message-ID: References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <5399C016.7090200@alum.mit.edu> In-Reply-To: <5399C016.7090200@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.129.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <251EEDFBDBC26F44899E58E49EB25C83@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7468 signatures=670466 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=6.49480469405717e-14 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-1406130188 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/98FK9mL9iiMdpq2lTSMAts-dmw8 Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 17:31:49 -0000 I did not complain about the dane-sip proposal because I think DANE is a bad fit for SIP - far from it. Nor do I insist that there is nothing whatsoever that we need to document to use DANE with SIP. However, the TLSA usage defined in ietf-dane-srv targets transport-layer security, as the name might suggest. I think that if the TLSA mechanism requires every application to do TLSA their own way, then we're going to end up with different credential needs for different applications and thus a very confusing deployment environment. Broadly, I consider the potential DANE environment to be a greenfield where we can hopefully create more uniformity in the way applications deal with multi-tenant situations and what have you. I therefore went back to the authors of ietf-dane-srv and asked them not to place a requirement for every application to define its own relationship to TLSA. The latest version of ietf-dane-srv no longer does. So, hopefully, the argument for a dane-sip draft is no longer that we are required to have one by ietf-dane-srv. There's also been some discussion in this thread of effectively deprecating the use of traditional certificates in SIP in favor of DANE. This would be premature, I think. We should however be working towards phasing in DANE in those environments where DNSSEC (and client support) are available, and in this work group doing any protocol work necessary as groundwork for that. Jon Peterson Neustar, Inc. On 6/12/14, 7:58 AM, "Paul Kyzivat" wrote: >Richard, Robert, Cullen, John, > >I believe you were the people most concerned with having use cases for >DANE. > >Do the cases brought up in this thread sufficient to satisfy you. >(Certainly these cases can be explained in more detail, but in general >to you consider them valid?) > > Thanks, > Paul > >On 6/12/14 6:11 AM, Olle E. Johansson wrote: >> >> On 11 Jun 2014, at 20:42, Paul Kyzivat wrote: >> >>> On 6/11/14 3:16 PM, Olle E. Johansson wrote: >>>> On 11 Jun 2014, at 20:03, Paul Kyzivat wrote: >>>>> I still think use cases can help here. Suppose all sip >>>>>implementations were capable of both 5922 and DANE. Then deployments >>>>>would need to decide when it would be advantageous to use DANE rather >>>>>than, or in addition to, DANE. What use cases can do is illustrate >>>>>when DANE is advantageous. >>>>> >>>>> If we can agree on cases were we want to use DANE, then we will have >>>>>better motivation to figure out what we must do to make that possible. >>>>> >>>>> This doesn't have to be just Olle - anybody can speak up. >>>>> >>>>> (We have the opportunity to discuss this further in Toronto, but >>>>>unless we have some action on the list first then we probably won't.) >>>>> >>>> >>>> RFC 5922 usage implies use of a CA that has a certificate that needs >>>>to be installed on every single phone. It also use certificates that >>>>are not available on the market - with SIP uri:s in the SAN extension >>>>fields. >>>> >>>> DANE can be used with a CA in the same mode, but also with no CA, >>>>which significantly makes it easier to use. The cost of managing a CA >>>>and getting the CA chain out on every device is rather high, because >>>>it's a complex operation if you want to have a trustworthy >>>>installation. >>> >>> OK. Good start! >>> >>> Does anybody disagree that these are important reasons? >>> >>> Isn't it also the case that having certificates follow the DNS >>>delegation chain also makes it much easier to deploy - avoiding the >>>need to share certs among multiple servers? >> >> Thanks for the reminder: >> >> Another benefit is that the server certificate only needs the server >>host name. With DANE you don't change the server cert when adding a new >>domain. >> >> With traditional certs - using DANE or not - you need a new certificate >>for any change in hosted domains. >> >> /O >> > From nobody Fri Jun 13 10: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 2CE4D1B27CA for ; Fri, 13 Jun 2014 10:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, 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 XzWqB6OQkzdT for ; Fri, 13 Jun 2014 10:44:55 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2031B293F for ; Fri, 13 Jun 2014 10:44:55 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id l13so806002iga.10 for ; Fri, 13 Jun 2014 10:44: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=XbjR1WYjDBSQi2o70Q64KlugmMjzOt4Fe0WrQNX5ycM=; b=XZ8GzvyEYlTV8/j/2pMlkyg8Ke2GqetpI3VXIOccI8gAc9mD+fnnH73YSW0eW8XtDf vD7IhO4OQN+5CG3iWfpf0mL66VmDXyzjFgYU3YZUczkZsMqVVmV1gBwZQxMwpJQCwPE1 iq+6e+NZZyStX7LyuvNMM49Wd8EToNVjHsDThqrtZNcttFGIyjYWCPv03LGTX8yMnHHQ 2fNggjyJDi0gTFXtyXcGxFM61uwiRptt9ccwJDVnYy5+4UUsAL+OCs0LXDf30Od9HPIx s0suoBHJu9BceMD2WJZiuuZL+H7h04s6PmAWYQgmfdSIGpb4dndAKmec44D8MR8GnGjF fC6A== MIME-Version: 1.0 X-Received: by 10.42.198.77 with SMTP id en13mr4981414icb.92.1402681494675; Fri, 13 Jun 2014 10:44:54 -0700 (PDT) Received: by 10.50.114.97 with HTTP; Fri, 13 Jun 2014 10:44:54 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> Date: Fri, 13 Jun 2014 13:44:54 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=90e6ba18221e3927fb04fbbb3c54 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/z44Z0QANtaF6afdoExgMbijPWG0 Cc: "sipcore@ietf.org" , Ivo Sedlacek Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 13 Jun 2014 17:44:58 -0000 --90e6ba18221e3927fb04fbbb3c54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jon, Yeah, that was my initial reaction to this request, as my intention was to keep this document aligned with RFC6749. Personally, I prefer to keep it aligned with RFC6749, but I can kind of see the argument of using an existing mechanism to keep it aligned with SIP in this specific case. The challenge-response mechanism defined in RFC2617 is now obsolete; it is now defined in RFC7235. The https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the process of doing the same for the Digest Scheme. The flow in section 4 carries the token in the 200 OK; one possible way to carry that in SIP is to use the Authentication-Info, which is *not* part of the challenge-response framework defined in RFC7235. The Authentication-Info is defined in the above Digest draft, which we could make sure that it is extendible (I just noticed that it is not extend= ible in the current version but I can fix that in the next version of the Digest draft). That would allow us to extend it for SIP, if that is what we want to do. I do not have strong opinion on this one; I can go either way. Regards, Rifaat On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon wrote: > > Well, the Authorization header field is defined in RFC2617, and the base > SIP specification instructs implementers to use its syntax. In other word= s, > these headers don't belong to us. The syntax and semantics of OAuth is > nothing like them. I don't think it's reasonable for us to just overload > the syntax and semantics of the HTTP authentication system in this way fo= r > SIP. Nor is it that case that by doing so in SIP, we will allow "any > protocol that uses these headers" to use OAuth - that's exactly backwards= . > What we'd be doing is creating fragmentation and confusion. > > Our OAuth usage should be aligned with HTTP's usage, that is, with > RFC6749. If we want something different, I think we need to talk to them > about it. > > Jon Peterson > Neustar, Inc. > > From: Rifaat Shekh-Yusef > Date: Friday, June 13, 2014 at 5:18 AM > To: Ivo Sedlacek > Cc: "sipcore@ietf.org" > > Subject: Re: [sipcore] SIP OAuth: Information element to carry token > > I am fine with this; I will make the change in the next version of the > draft. > > Regards, > Rifaat > > > > On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek > wrote: > >> Hello, >> >> >> >> I share the same view as Christer. >> >> >> >> New authentication schemes should preferably extend / re-use the headers >> defined for authentication (i.e. WWW-Authenticate, Authorization, >> Authentication-Info, Proxy-Authenticate, Proxy-Authorization). >> >> >> >> This would enable usage of the OAuth method in any protocol which uses >> those headers. >> >> >> >> This would enable usage of the OAuth method in (a) authentication with >> proxy and (b) authentication with server. >> >> >> >> Kind regards >> >> >> >> Ivo Sedlacek >> >> >> >> This Communication is Confidential. We only send and receive email on th= e >> basis of the terms set out at www.ericsson.com/email_disclaimer >> >> >> *From:* sipcore [mailto:sipcore-bounces@ietf.org >> ] *On Behalf Of *Rifaat Shekh-Yusef >> *Sent:* 12. =C4=8Dervna 2014 18:58 >> *To:* Christer Holmberg >> *Cc:* sipcore@ietf.org >> *Subject:* Re: [sipcore] SIP OAuth: Information element to carry token >> >> >> >> Hi Christer, >> >> >> >> I tried to keep this proposal aligned with approach taken by RFC6749, bu= t >> I think that using Authorization header would be a valid option too. >> >> Is there any reason that you prefer it to be carried in the Authorizatio= n >> header instead of the message body? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> Hi, >> >> >> >> I was taking a look at draft-yusef-sipcore-sip-oauth-00. >> >> >> >> In section 4, I see that the OAuth token is carried in a message body. I= s >> there a reason why one could not use the SIP Authorization header field= ? >> >> >> >> Regards, >> >> >> >> Christer >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> > > --90e6ba18221e3927fb04fbbb3c54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jon,

Yeah, that was my initial react= ion to this request, as my intention was to keep this document aligned with= RFC6749.
Personally, I prefer t= o keep it aligned with=C2=A0RFC6749, but I can kind of see the argum= ent of using an existing mechanism to keep it aligned with SIP in this spec= ific case.

The challenge-response mechanism defined in RFC2617 is = now obsolete; it is now defined in=C2=A0RFC7235.
The=C2=A0https://datatracker.ietf.org/doc/draft-ie= tf-httpauth-digest/ is in the process of doing the same for the Digest = Scheme.

The flow in section 4 carries the token in the 200 OK; on= e possible way to carry that in SIP is to use the=C2=A0Authentication-Info,= which is not part of the challenge-response framework defined in RF= C7235.
The=C2=A0Authentication-Info is defin= ed in the above Digest draft, which we could make sure that it is=C2=A0exte= ndible (I just noticed that it is not=C2=A0extendible in the current version but I can fix that in= the next version of the Digest draft).
That would allow us to extend it for = SIP, if that is what we want to do.

I do not have strong opinion on this one; = I can go either way.

Regards,



On Fri, Jun 1= 3, 2014 at 12:48 PM, Peterson, Jon <jon.peterson@neustar.biz>= ; wrote:

Well, the Authorization header field is defined in RFC2617, and the ba= se SIP specification instructs implementers to use its syntax. In other wor= ds, these headers don't belong to us. The syntax and semantics of OAuth= is nothing like them. I don't think it's reasonable for us to just overload the syntax and semantics of th= e HTTP authentication system in this way for SIP. =C2=A0Nor is it that case= that by doing so in SIP, we will allow "any protocol that uses these = headers" to use OAuth - that's exactly backwards. What we'd be doing is creating fragmentation and confusion.=C2=A0

Our OAuth usage should be aligned with HTTP's usage, that is, with= RFC6749. If we want something different, I think we need to talk to them a= bout it.

Jon Peterson
Neustar, Inc.


I am fine with this; I will make the change in the next ve= rsion of the draft.

Regards,
=C2=A0Rifaat



On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <ivo.sedl= acek@ericsson.com> wrote:

Hello,

=C2=A0

I share the same view as Christer.

=C2=A0

New authentication schemes should preferably e= xtend / re-use the headers defined for authentication (i.e. WWW-Authenticat= e, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

=C2=A0

This would enable usage of the OAuth method in= any protocol which uses those headers.

=C2=A0

This would enable usage of the OAuth method in= (a) authentication with proxy and (b) authentication with server.

=C2=A0

Kind regards

=C2=A0

Ivo Sedlacek

=C2=A0

This Communication is Confidential. We only send= and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. =C4=8Dervna 2014 18:58
To: Christer Holmberg
Cc: sipcore@ie= tf.org
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

=C2=A0

Hi Christer,

=C2=A0

I tried to keep this proposal aligned with approach = taken by RFC6749, but I think that using Authorization header would be a va= lid option too.

Is there any reason that you prefer it to be carried= in the Authorization header instead of the message body?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0<= /p>

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

I was taking a look at draft-yusef-sipcore-sip-oauth-00.

=C2=A0

In section 4, I see that the OAuth token i= s carried in a message body. Is there a reason why=C2=A0one could not use= =C2=A0 the SIP Authorization header field?

=C2=A0

Regards,

=C2=A0

Christer=


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

=C2=A0

--90e6ba18221e3927fb04fbbb3c54-- From nobody Fri Jun 13 11:45: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 413291B29F4 for ; Fri, 13 Jun 2014 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, 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 4krk6I305fCm for ; Fri, 13 Jun 2014 11:45:06 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E12551B29F0 for ; Fri, 13 Jun 2014 11:45:05 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA11.westchester.pa.mail.comcast.net with comcast id DuhP1o00b1ei1Bg5Bul5Wv; Fri, 13 Jun 2014 18:45:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Dul41o00z3ZTu2S3kul5WG; Fri, 13 Jun 2014 18:45:05 +0000 Message-ID: <539B46B0.1030909@alum.mit.edu> Date: Fri, 13 Jun 2014 14:45:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Peterson, Jon" , Richard Barnes , Cullen Jennings , Robert Sparks References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <5399C016.7090200@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=1402685105; bh=OFuaK4sTLwxcBOkU3DXVHhTKpX72VJyiFc1vm4RXo18=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bPn03TyKc34sMnQ/I9XHvKnBJw8gxqRd6DZ3kUKw/dCXos94HteUl48YyAxAoJdbg 5E01SS4C4zG0F69VPAcCpozWZIB80UFP/BjBuTfzrLP5S7pvGdYNJ6XtAp2Rld64Io SYHfKvQKVWUmXV2qTgTeu7RPsEI4mP14pKcQeBO7mWm+6JI9eofp76bYCRapxfBw1y CQAz6/1+POsde3I5W0PDK2PN+3WRk1vrmFEEiGER+SigCLoChDkh5BjiQrfcXhdTxz o9aADQjyp7Xu61szZiFcLrMDTMXoVesn0kcX0Wx6s10b3KmxrG7dG3kaxeWBkN+0Md 8j8Jjp4QywIDw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/VeeQrIneyl9Qg0oWfDjX7GB842M Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 18:45:07 -0000 On 6/13/14 1:31 PM, Peterson, Jon wrote: > > I did not complain about the dane-sip proposal because I think DANE is a > bad fit for SIP - far from it. Nor do I insist that there is nothing > whatsoever that we need to document to use DANE with SIP. However, the > TLSA usage defined in ietf-dane-srv targets transport-layer security, as > the name might suggest. I think that if the TLSA mechanism requires every > application to do TLSA their own way, then we're going to end up with > different credential needs for different applications and thus a very > confusing deployment environment. > > Broadly, I consider the potential DANE environment to be a greenfield > where we can hopefully create more uniformity in the way applications deal > with multi-tenant situations and what have you. I therefore went back to > the authors of ietf-dane-srv and asked them not to place a requirement for > every application to define its own relationship to TLSA. The latest > version of ietf-dane-srv no longer does. I see that there have been a number of changes to achieve this. Thanks for pushing that! > So, hopefully, the argument for a > dane-sip draft is no longer that we are required to have one by > ietf-dane-srv. ietf-dane-srv now has a new section "Guidance for Application Protocols" that gives a list of things that an application specific document could cover. It doesn't require these, but I take it that if the shoe fits then wear it. We should certainly have the discussion of what we do need to say. > There's also been some discussion in this thread of effectively > deprecating the use of traditional certificates in SIP in favor of DANE. > This would be premature, I think. +1 Perhaps the traditional use will be supplanted by DANE because of the benefits that ensue. We don't need to get too far in front of that. ISTM that a major issue is backward compatibility, and the chicken/egg problem: there is no motivation for clients to deploy the DANE logic until there are servers that can use it, and there is no reason for servers to use it until there are clients supporting it. IIUC most of the benefits accrue to servers, but only after it can be assumed that all clients support it. That makes for a hard migration. > We should however be working towards > phasing in DANE in those environments where DNSSEC (and client support) > are available, and in this work group doing any protocol work necessary as > groundwork for that. I'm not sure who you mean by "we". ISTM this is a deployment issue, not a standards issue. Thanks, Paul > Jon Peterson > Neustar, Inc. > > On 6/12/14, 7:58 AM, "Paul Kyzivat" wrote: > >> Richard, Robert, Cullen, John, >> >> I believe you were the people most concerned with having use cases for >> DANE. >> >> Do the cases brought up in this thread sufficient to satisfy you. >> (Certainly these cases can be explained in more detail, but in general >> to you consider them valid?) >> >> Thanks, >> Paul >> >> On 6/12/14 6:11 AM, Olle E. Johansson wrote: >>> >>> On 11 Jun 2014, at 20:42, Paul Kyzivat wrote: >>> >>>> On 6/11/14 3:16 PM, Olle E. Johansson wrote: >>>>> On 11 Jun 2014, at 20:03, Paul Kyzivat wrote: >>>>>> I still think use cases can help here. Suppose all sip >>>>>> implementations were capable of both 5922 and DANE. Then deployments >>>>>> would need to decide when it would be advantageous to use DANE rather >>>>>> than, or in addition to, DANE. What use cases can do is illustrate >>>>>> when DANE is advantageous. >>>>>> >>>>>> If we can agree on cases were we want to use DANE, then we will have >>>>>> better motivation to figure out what we must do to make that possible. >>>>>> >>>>>> This doesn't have to be just Olle - anybody can speak up. >>>>>> >>>>>> (We have the opportunity to discuss this further in Toronto, but >>>>>> unless we have some action on the list first then we probably won't.) >>>>>> >>>>> >>>>> RFC 5922 usage implies use of a CA that has a certificate that needs >>>>> to be installed on every single phone. It also use certificates that >>>>> are not available on the market - with SIP uri:s in the SAN extension >>>>> fields. >>>>> >>>>> DANE can be used with a CA in the same mode, but also with no CA, >>>>> which significantly makes it easier to use. The cost of managing a CA >>>>> and getting the CA chain out on every device is rather high, because >>>>> it's a complex operation if you want to have a trustworthy >>>>> installation. >>>> >>>> OK. Good start! >>>> >>>> Does anybody disagree that these are important reasons? >>>> >>>> Isn't it also the case that having certificates follow the DNS >>>> delegation chain also makes it much easier to deploy - avoiding the >>>> need to share certs among multiple servers? >>> >>> Thanks for the reminder: >>> >>> Another benefit is that the server certificate only needs the server >>> host name. With DANE you don't change the server cert when adding a new >>> domain. >>> >>> With traditional certs - using DANE or not - you need a new certificate >>> for any change in hosted domains. >>> >>> /O >>> >> > > From nobody Fri Jun 13 12:46: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 941F61B29D0 for ; Fri, 13 Jun 2014 12:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 LVxNjC9erirE for ; Fri, 13 Jun 2014 12:46:12 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC811B2A25 for ; Fri, 13 Jun 2014 12:46:12 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5DJk6hD024580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jun 2014 14:46:07 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5DJk65d006604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jun 2014 14:46:06 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5DJk3D8009532; Fri, 13 Jun 2014 14:46:03 -0500 (CDT) Message-ID: <539B558A.6090402@bell-labs.com> Date: Fri, 13 Jun 2014 14:48:26 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Olle E. Johansson" References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> <943E1DBE-7A46-42F1-92CB-651CB39BAB14@edvina.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/vRGeNIP7iToO9swKYZ-e1sq_fZ4 Cc: SIPCORE Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 19:46:14 -0000 On 06/13/2014 06:18 AM, Iñaki Baz Castillo wrote: > 2014-06-13 13:14 GMT+02:00 Olle E. Johansson : >> No, but the world needs to move to DANE and forget the rest... > > Please add "This document deprecates and looks down RFC 5922". Before we hastily throw out the baby with the bathwater, it seems to me that the crux of the problem is as Iñaki described in an earlier email; to wit: Both SIP-cert and DANE perform two steps: 1) Get a certificate. 2) Decide which domain must be used to check the received certificate. 3) Check the certificate. Step 1 is the same for both. Step 2 is different (SIP-cert uses the domain before DNS procedures while DANE uses the domain after DNS procedures). Step 3 is obviously different (right). When the work that lead to rfc5922 was done, the constraints were that the identity encoded in the certificate (preferably in a subjectAltName, or less preferably in CN) match the URI that the user uses to establish the session. Therefore, if someone establishes a session with me using sips:vkg@example.com then the certificate presented by my domain's proxy best assert an identity of sip:example.com in the certificate. Has this constraint, i.e., the identity encoded in a certificate can be different than the one used to procure a host that is responsible for that certificate, now been relaxed? If the answer is affirmative, then by all means go ahead and throw both the baby and the bathwater out. But if --- as Paul noted --- that "there is no motivation for clients to deploy the DANE logic until there are servers that can use it, and there is no reason for servers to use it until there are clients supporting it." then I am at a loss to see how moving to DANE will foster faster support when the same chicken-and-egg problem haunted rfc5922 as well? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri Jun 13 16:40: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 A581F1B27E1 for ; Fri, 13 Jun 2014 16:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 LOQpqBjPVYY2 for ; Fri, 13 Jun 2014 16:40:16 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861B71A02B8 for ; Fri, 13 Jun 2014 16:40:16 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 159601E042; Fri, 13 Jun 2014 23:40:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1402702815; bh=dpAtGzY2Und+/4uYHHoiLVqBtx2GWRlVv8zwH5/vhv0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=etCw0YDrSI7thsvNU8duqztfo37rdDIaKo7gCol1ssNLwbiC/mUivOGVa7e2yg2hS b2WNWwrSjmae8lonqh6XY9rHxpZaJFTkIVzCJIyj26HjJSzZAP7UR4+vGW+Wbq6VXx 3CXJqUFxeMcts6ZBb4xQ63eo1OsKvXlfH2ZjIChI= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 2B8B56001E; Fri, 13 Jun 2014 23:36:07 +0000 (UTC) From: James Cloos To: "Vijay K. Gurbani" In-Reply-To: <539B558A.6090402@bell-labs.com> (Vijay K. Gurbani's message of "Fri, 13 Jun 2014 14:48:26 -0500") References: <5398A7F9.7030101@alum.mit.edu> <5398B124.2080901@alum.mit.edu> <3BD43DB9-7336-48C1-8C45-53A750D56F46@edvina.net> <3B29CAD2-72B9-4D56-83F3-29BCB12B364A@edvina.net> <943E1DBE-7A46-42F1-92CB-651CB39BAB14@edvina.net> <539B558A.6090402@bell-labs.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 13 Jun 2014 19:36:07 -0400 Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140613:vkg@bell-labs.com::f/v9VdPbkaP/E9B1:0000000000000000000000000000000000000000000jq7sN X-Hashcash: 1:30:140613:ibc@aliax.net::yOg3mY0vG8rLxmT+:000apstV Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/__rxTBSVrHPcnWODzOQ-FqbD1UU Cc: =?iso-8859-1?Q?I=F1aki?= Baz Castillo , SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Proceeding with dane-sip 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, 13 Jun 2014 23:40:17 -0000 >>>>> "VG" == Vijay K Gurbani writes: VG> Step 1 is the same for both. VG> Step 2 is different (SIP-cert uses the domain before DNS procedures VG> while DANE uses the domain after DNS procedures). VG> Step 3 is obviously different (right). The current draft recommends that clients accept either the before or the after in step 2. The tlsa, of course, has to be configured to match the cert which the server offers no matter what style of cert it is. And a 3 1 x tlsa specifies that the client should ignore all of the pkix aspects of the cert, and just verify the key. That means that adding a 3 1 x tlsa to any existing setup will, if everything is dnssec-signed, be enough for any dane-enabled client. No changes to the server's setup are required beyond adding the tlsa and signing the dns. Over time, as more clients switch to dane, the servers can stop providing backwards compatibility, but there is no rush to do so. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat Jun 14 01:32: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 0714D1B2BD8 for ; Sat, 14 Jun 2014 01:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 w789uvIOyAkl for ; Sat, 14 Jun 2014 01:32:21 -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 F13641B2BD7 for ; Sat, 14 Jun 2014 01:32:20 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-6f-539c08925589 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.52.16420.2980C935; Sat, 14 Jun 2014 10:32:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Sat, 14 Jun 2014 10:32:18 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef , "Peterson, Jon" Thread-Topic: [sipcore] SIP OAuth: Information element to carry token Thread-Index: Ac+GXAtV4bffJBdGSQCga8JWstB7EP//5UaA//8AVuCAAkPVAIAAS3oAgAAP1QCAARjVeg== Date: Sat, 14 Jun 2014 08:32:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D37208F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D37208FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rncyx5xgg72/WCzONFha7HzRymbx 9ccmNgdmj52z7rJ7LFnyk8ljR8Nz5gDmKC6blNSczLLUIn27BK6MdZsvMxU8XcRYcbTDooHx ei9jFyMHh4SAicShq3VdjJxAppjEhXvr2boYuTiEBI4ySsxac4wJwlnEKPFtziJWkAY2AQuJ 7n/aIA0iAjESHyZ2sYDYzAKhEku/rWMDsYUFXCS6fi1mg6hxldi4ajkLhB0mcenmTmYQm0VA VWLWvHmsIDavgK/EtZ4f7BC7JjJLnNx0GizBKRAocXTaE3YQmxHouu+n1jBBLBOXuPVkPhPE 1QISS/acZ4awRSVePv7HCmErSuw8284MUZ8vsXDaOTaIZYISJ2c+YZnAKDoLyahZSMpmISmD iOtJPDs1C8rWlli28DUzhK0rcenhOlZk8QWM7KsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYx AmPw4JbfqjsYL79xPMQowMGoxMOrYDM7WIg1say4MvcQozQHi5I47/0vs4KFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MNqtS9z8TTp8M+f9ILdrn06xCTtWmsYHdz480/SQbTZj6IzpXous ll2Vd3u7l+HsYcE51ilTP615cPfAAU7xzOosI9Et5zPKXXO0jKteq00o/vPZNCzjWmHnBdew f69CUv2v5n9PXf2nxT15ysU0yWmfmfNXuvf9Oi7ta8R3pvx7X8vBHN33jUosxRmJhlrMRcWJ AOAK5vuiAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/YSTQADR4gZ1Iyvs_WJ7TZalA6kY Cc: "sipcore@ietf.org" , Ivo Sedlacek Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 14 Jun 2014 08:32:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D37208FESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, My initial question was why existing SIP header fields weren't used. IF the= re are good reasons (e.g. based on Jon's input) I think it would be useful = to document those in the draft. Regards, Christer ________________________________ From: sipcore [sipcore-bounces@ietf.org] on behalf of Rifaat Shekh-Yusef [r= ifaat.ietf@gmail.com] Sent: Friday, 13 June 2014 8:44 PM To: Peterson, Jon Cc: sipcore@ietf.org; Ivo Sedlacek Subject: Re: [sipcore] SIP OAuth: Information element to carry token Hi Jon, Yeah, that was my initial reaction to this request, as my intention was to = keep this document aligned with RFC6749. Personally, I prefer to keep it aligned with RFC6749, but I can kind of see= the argument of using an existing mechanism to keep it aligned with SIP in= this specific case. The challenge-response mechanism defined in RFC2617 is now obsolete; it is = now defined in RFC7235. The https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the = process of doing the same for the Digest Scheme. The flow in section 4 carries the token in the 200 OK; one possible way to = carry that in SIP is to use the Authentication-Info, which is not part of t= he challenge-response framework defined in RFC7235. The Authentication-Info is defined in the above Digest draft, which we coul= d make sure that it is extendible (I just noticed that it is not extendible= in the current version but I can fix that in the next version of the Diges= t draft). That would allow us to extend it for SIP, if that is what we want to do. I do not have strong opinion on this one; I can go either way. Regards, Rifaat On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon > wrote: Well, the Authorization header field is defined in RFC2617, and the base SI= P specification instructs implementers to use its syntax. In other words, t= hese headers don't belong to us. The syntax and semantics of OAuth is nothi= ng like them. I don't think it's reasonable for us to just overload the syn= tax and semantics of the HTTP authentication system in this way for SIP. N= or is it that case that by doing so in SIP, we will allow "any protocol tha= t uses these headers" to use OAuth - that's exactly backwards. What we'd be= doing is creating fragmentation and confusion. Our OAuth usage should be aligned with HTTP's usage, that is, with RFC6749.= If we want something different, I think we need to talk to them about it. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Friday, June 13, 2014 at 5:18 AM To: Ivo Sedlacek > Cc: "sipcore@ietf.org" > Subject: Re: [sipcore] SIP OAuth: Information element to carry token I am fine with this; I will make the change in the next version of the draf= t. Regards, Rifaat On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek > wrote: Hello, I share the same view as Christer. New authentication schemes should preferably extend / re-use the headers de= fined for authentication (i.e. WWW-Authenticate, Authorization, Authenticat= ion-Info, Proxy-Authenticate, Proxy-Authorization). This would enable usage of the OAuth method in any protocol which uses thos= e headers. This would enable usage of the OAuth method in (a) authentication with prox= y and (b) authentication with server. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Y= usef Sent: 12. =E8ervna 2014 18:58 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP OAuth: Information element to carry token Hi Christer, I tried to keep this proposal aligned with approach taken by RFC6749, but I= think that using Authorization header would be a valid option too. Is there any reason that you prefer it to be carried in the Authorization h= eader instead of the message body? Regards, Rifaat On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg > wrote: Hi, I was taking a look at draft-yusef-sipcore-sip-oauth-00. In section 4, I see that the OAuth token is carried in a message body. Is t= here a reason why one could not use the SIP Authorization header field? Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1D37208FESESSMB209erics_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi,

 

My initial question was why existing SIP header fields weren't used. IF&= nbsp;there are good reasons (e.g. based on Jon's input) I think it wou= ld be useful to document those in the draft.

 

Regards,

 

Christer

 

 

 

From: sipcore [sipcore-bounces@ietf.org] o= n behalf of Rifaat Shekh-Yusef [rifaat.ietf@gmail.com]
Sent: Friday, 13 June 2014 8:44 PM
To: Peterson, Jon
Cc: sipcore@ietf.org; Ivo Sedlacek
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

Hi Jon,

Yeah, that was my initial reaction to this request, as my intention wa= s to keep this document aligned with RFC6749.
Personally, I prefer to keep it align= ed with RFC6749, but I can kind of see the argument of using an= existing mechanism to keep it aligned with SIP in this specific case.

The challenge-response mechanism defined in RFC2617 is now obsolete; i= t is now defined in RFC7235.
The https://data= tracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the process of d= oing the same for the Digest Scheme.

The flow in section 4 carries the tok= en in the 200 OK; one possible way to carry that in SIP is to use the = Authentication-Info, which is not part of the challenge-response framework defined in RFC7235.
The Authentication-Info is defin= ed in the above Digest draft, which we could make sure that it is exte= ndible (I just noticed that it is not extendible in the current version but I can fix that in the next version of the Digest draft).
That would allow us to extend it for = SIP, if that is what we want to do.

I do not have strong opinion on this one; I can go either way.

Regards,
 Rifaat



On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon = <jon.peter= son@neustar.biz> wrote:

Well, the Authorization header field is defined in RFC2617, and the ba= se SIP specification instructs implementers to use its syntax. In other wor= ds, these headers don't belong to us. The syntax and semantics of OAuth is = nothing like them. I don't think it's reasonable for us to just overload the syntax and semantics of the HT= TP authentication system in this way for SIP.  Nor is it that case tha= t by doing so in SIP, we will allow "any protocol that uses these head= ers" to use OAuth - that's exactly backwards. What we'd be doing is creating fragmentation and confusion. 

Our OAuth usage should be aligned with HTTP's usage, that is, with RFC= 6749. If we want something different, I think we need to talk to them about= it.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com= >
Date: Friday, June 13, 2014 at 5:1= 8 AM
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com= >
Cc: "sipcore@ietf.org" <sipcore@ietf.org>

Subject: Re: [sipcore] SIP OAuth: = Information element to carry token

I am fine with this; I will make the change in the next ve= rsion of the draft.

Regards,
 Rifaat



On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <ivo.sedl= acek@ericsson.com> wrote:

Hello,

 

I share the same view as Christer.=

 

New authentication schemes should prefera= bly extend / re-use the headers defined for authentication (i.e. WWW-Authen= ticate, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

 

This would enable usage of the OAuth meth= od in any protocol which uses those headers.

 

This would enable usage of the OAuth meth= od in (a) authentication with proxy and (b) authentication with server.<= /u>

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We only= send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. =E8ervna 2014 18:58
To: Christer Holmberg
Cc: sipcore@ie= tf.org
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

 

Hi Christer,

 

I tried to keep this proposal aligned with approach = taken by RFC6749, but I think that using Authorization header would be a va= lid option too.

Is there any reason that you prefer it to be carried= in the Authorization header instead of the message body?

 

Regards,

 Rifaat

 

 

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

I was taking a look at draft-yusef-sipcore-sip-oauth-00.<= u>

 

In section 4, I see that the OAuth to= ken is carried in a message body. Is there a reason why one could not = use  the SIP Authorization header field?

 

Regards,

 

Christer


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

 



--_000_7594FB04B1934943A5C02806D1A2204B1D37208FESESSMB209erics_-- From nobody Sun Jun 15 13:02: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 A29771B297F for ; Sun, 15 Jun 2014 13:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-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 8100xgcUgkMV for ; Sun, 15 Jun 2014 13:02:46 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9054B1B296D for ; Sun, 15 Jun 2014 13:02:46 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5FK2cTr020768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jun 2014 15:02:39 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5FK2ZnF011588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Jun 2014 22:02:35 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 15 Jun 2014 22:02:35 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Rifaat Shekh-Yusef , "Peterson, Jon" Thread-Topic: [sipcore] SIP OAuth: Information element to carry token Thread-Index: Ac+GXAtV4bffJBdGSQCga8JWstB7EAAJO3CAABwjqwAADGHGAP//1gQAgAAgtQCAAPfwAP/9pziw Date: Sun, 15 Jun 2014 20:02:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1EDA28@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> , <7594FB04B1934943A5C02806D1A2204B1D37208F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D37208F@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B1EDA28FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Z9jZQQjHHeQ5Tbt1xuGnTeSXKWw Cc: "sipcore@ietf.org" , Ivo Sedlacek Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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: Sun, 15 Jun 2014 20:02:49 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B1EDA28FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I suspect there are two steps to this question. 1) Given that there are some differences between HTTP and SIP, would it = be more appropriate to use a header field rather than a message body? 2) If a header field is used, should it be an extension of an existing h= eader field or a new one? regards Keith ________________________________ From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 14 June 2014 09:32 To: Rifaat Shekh-Yusef; Peterson, Jon Cc: sipcore@ietf.org; Ivo Sedlacek Subject: Re: [sipcore] SIP OAuth: Information element to carry token Hi, My initial question was why existing SIP header fields weren't used. IF the= re are good reasons (e.g. based on Jon's input) I think it would be useful = to document those in the draft. Regards, Christer ________________________________ From: sipcore [sipcore-bounces@ietf.org] on behalf of Rifaat Shekh-Yusef [r= ifaat.ietf@gmail.com] Sent: Friday, 13 June 2014 8:44 PM To: Peterson, Jon Cc: sipcore@ietf.org; Ivo Sedlacek Subject: Re: [sipcore] SIP OAuth: Information element to carry token Hi Jon, Yeah, that was my initial reaction to this request, as my intention was to = keep this document aligned with RFC6749. Personally, I prefer to keep it aligned with RFC6749, but I can kind of see= the argument of using an existing mechanism to keep it aligned with SIP in= this specific case. The challenge-response mechanism defined in RFC2617 is now obsolete; it is = now defined in RFC7235. The https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the = process of doing the same for the Digest Scheme. The flow in section 4 carries the token in the 200 OK; one possible way to = carry that in SIP is to use the Authentication-Info, which is not part of t= he challenge-response framework defined in RFC7235. The Authentication-Info is defined in the above Digest draft, which we coul= d make sure that it is extendible (I just noticed that it is not extendible= in the current version but I can fix that in the next version of the Diges= t draft). That would allow us to extend it for SIP, if that is what we want to do. I do not have strong opinion on this one; I can go either way. Regards, Rifaat On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon > wrote: Well, the Authorization header field is defined in RFC2617, and the base SI= P specification instructs implementers to use its syntax. In other words, t= hese headers don't belong to us. The syntax and semantics of OAuth is nothi= ng like them. I don't think it's reasonable for us to just overload the syn= tax and semantics of the HTTP authentication system in this way for SIP. N= or is it that case that by doing so in SIP, we will allow "any protocol tha= t uses these headers" to use OAuth - that's exactly backwards. What we'd be= doing is creating fragmentation and confusion. Our OAuth usage should be aligned with HTTP's usage, that is, with RFC6749.= If we want something different, I think we need to talk to them about it. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Friday, June 13, 2014 at 5:18 AM To: Ivo Sedlacek > Cc: "sipcore@ietf.org" > Subject: Re: [sipcore] SIP OAuth: Information element to carry token I am fine with this; I will make the change in the next version of the draf= t. Regards, Rifaat On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek > wrote: Hello, I share the same view as Christer. New authentication schemes should preferably extend / re-use the headers de= fined for authentication (i.e. WWW-Authenticate, Authorization, Authenticat= ion-Info, Proxy-Authenticate, Proxy-Authorization). This would enable usage of the OAuth method in any protocol which uses thos= e headers. This would enable usage of the OAuth method in (a) authentication with prox= y and (b) authentication with server. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Y= usef Sent: 12. =E8ervna 2014 18:58 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP OAuth: Information element to carry token Hi Christer, I tried to keep this proposal aligned with approach taken by RFC6749, but I= think that using Authorization header would be a valid option too. Is there any reason that you prefer it to be carried in the Authorization h= eader instead of the message body? Regards, Rifaat On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg > wrote: Hi, I was taking a look at draft-yusef-sipcore-sip-oauth-00. In section 4, I see that the OAuth token is carried in a message body. Is t= here a reason why one could not use the SIP Authorization header field? Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_949EF20990823C4C85C18D59AA11AD8B1EDA28FR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
I suspect there are two steps to = this question.
 
1)    Given that t= here are some differences between HTTP and SIP, would it be more appropriat= e to use a header field rather than a message body?
 
2)    If a header = field is used, should it be an extension of an existing header field or a n= ew one?
 
regards
 
Keith

From: sipcore [mailto:sipcore-bounc= es@ietf.org] On Behalf Of Christer Holmberg
Sent: 14 June 2014 09:32
To: Rifaat Shekh-Yusef; Peterson, Jon
Cc: sipcore@ietf.org; Ivo Sedlacek
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

Hi,

 

My initial question was why existing SIP header fields weren't used. IF&= nbsp;there are good reasons (e.g. based on Jon's input) I think it wou= ld be useful to document those in the draft.

 

Regards,

 

Christer

 

 

 

From: sipcore [sipcore-bounces@ietf.org] o= n behalf of Rifaat Shekh-Yusef [rifaat.ietf@gmail.com]
Sent: Friday, 13 June 2014 8:44 PM
To: Peterson, Jon
Cc: sipcore@ietf.org; Ivo Sedlacek
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

Hi Jon,

Yeah, that was my initial reaction to this request, as my intention wa= s to keep this document aligned with RFC6749.
Personally, I prefer to keep it align= ed with RFC6749, but I can kind of see the argument of using an= existing mechanism to keep it aligned with SIP in this specific case.

The challenge-response mechanism defined in RFC2617 is now obsolete; i= t is now defined in RFC7235.
The https://data= tracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the process of d= oing the same for the Digest Scheme.

The flow in section 4 carries the tok= en in the 200 OK; one possible way to carry that in SIP is to use the = Authentication-Info, which is not part of the challenge-response framework defined in RFC7235.
The Authentication-Info is defin= ed in the above Digest draft, which we could make sure that it is exte= ndible (I just noticed that it is not extendible in the current version but I can fix that in the next version of the Digest draft).
That would allow us to extend it for = SIP, if that is what we want to do.

I do not have strong opinion on this one; I can go either way.

Regards,
 Rifaat



On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon = <jon.peter= son@neustar.biz> wrote:

Well, the Authorization header field is defined in RFC2617, and the ba= se SIP specification instructs implementers to use its syntax. In other wor= ds, these headers don't belong to us. The syntax and semantics of OAuth is = nothing like them. I don't think it's reasonable for us to just overload the syntax and semantics of the HT= TP authentication system in this way for SIP.  Nor is it that case tha= t by doing so in SIP, we will allow "any protocol that uses these head= ers" to use OAuth - that's exactly backwards. What we'd be doing is creating fragmentation and confusion. 

Our OAuth usage should be aligned with HTTP's usage, that is, with RFC= 6749. If we want something different, I think we need to talk to them about= it.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com= >
Date: Friday, June 13, 2014 at 5:1= 8 AM
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com= >
Cc: "sipcore@ietf.org" <sipcore@ietf.org>

Subject: Re: [sipcore] SIP OAuth: = Information element to carry token

I am fine with this; I will make the change in the next ve= rsion of the draft.

Regards,
 Rifaat



On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <ivo.sedl= acek@ericsson.com> wrote:

Hello,

 

I share the same view as Christer.=

 

New authentication schemes should prefera= bly extend / re-use the headers defined for authentication (i.e. WWW-Authen= ticate, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

 

This would enable usage of the OAuth meth= od in any protocol which uses those headers.

 

This would enable usage of the OAuth meth= od in (a) authentication with proxy and (b) authentication with server.<= /u>

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We only= send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. =E8ervna 2014 18:58
To: Christer Holmberg
Cc: sipcore@ie= tf.org
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

 

Hi Christer,

 

I tried to keep this proposal aligned with approach = taken by RFC6749, but I think that using Authorization header would be a va= lid option too.

Is there any reason that you prefer it to be carried= in the Authorization header instead of the message body?

 

Regards,

 Rifaat

 

 

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

I was taking a look at draft-yusef-sipcore-sip-oauth-00.<= u>

 

In section 4, I see that the OAuth to= ken is carried in a message body. Is there a reason why one could not = use  the SIP Authorization header field?

 

Regards,

 

Christer


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

 



--_000_949EF20990823C4C85C18D59AA11AD8B1EDA28FR712WXCHMBA11zeu_-- From nobody Mon Jun 16 05:39: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 1D8931A0009 for ; Mon, 16 Jun 2014 05:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, 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 qv_rHDoO_09h for ; Mon, 16 Jun 2014 05:39:06 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A67F1A0008 for ; Mon, 16 Jun 2014 05:39:06 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so2869931igd.2 for ; Mon, 16 Jun 2014 05:39: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 :cc:content-type; bh=/NRvo4jBmoY6+PQhr/Ing5CyxF7RgeTxLqzsRoXileo=; b=oAwHd0HeArMuEH538O3aVfaP4YdCZsGrCI3Xcb5RfMAtDBMCscjOon2T8UhHu2NNo6 VZohQX12gk/iGgv/gka5LBxjgrybFXL9Hsgrx3DEW19wb4pKtN60TCEOT0OISkv1pKSe dBCocyud9K50SIGOKUp+LVOss29BcPq8iNk0I3IsB1sZTmJVTUSuMYMjkQwir/jdAIpD lsmTUPUf+xWzA0POvVWhOYWXHSIRH75sRPU0lU9+VnptTJ2NhEC85qKiHXkNn6eMosxO MhDnmsXcSsmmiMPMbzaEVmWF7butVn4Vxrw8p0KE+KOldmItafTrbkGan0a8AuxEWrrU OU6A== MIME-Version: 1.0 X-Received: by 10.50.141.164 with SMTP id rp4mr25475402igb.20.1402922345941; Mon, 16 Jun 2014 05:39:05 -0700 (PDT) Received: by 10.50.114.97 with HTTP; Mon, 16 Jun 2014 05:39:05 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1EDA28@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D37208F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B1EDA28@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 16 Jun 2014 08:39:05 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=089e0129538013cd6b04fbf35036 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/7C0mkqLaAo5wVUbti1lX7Asgg2w Cc: "sipcore@ietf.org" , Ivo Sedlacek Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 16 Jun 2014 12:39:09 -0000 --089e0129538013cd6b04fbf35036 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Keith, Where do you stand on these two questions? Regards, Rifaat On Sun, Jun 15, 2014 at 4:02 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I suspect there are two steps to this question. > > 1) Given that there are some differences between HTTP and SIP, would i= t > be more appropriate to use a header field rather than a message body? > > 2) If a header field is used, should it be an extension of an existing > header field or a new one? > > regards > > Keith > > ------------------------------ > *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 14 June 2014 09:32 > *To:* Rifaat Shekh-Yusef; Peterson, Jon > > *Cc:* sipcore@ietf.org; Ivo Sedlacek > *Subject:* Re: [sipcore] SIP OAuth: Information element to carry token > > Hi, > > > > My initial question was why existing SIP header fields weren't used. > IF there are good reasons (e.g. based on Jon's input) I think it would be > useful to document those in the draft. > > > > Regards, > > > > Christer > > > > > > > ------------------------------ > *From:* sipcore [sipcore-bounces@ietf.org] on behalf of Rifaat > Shekh-Yusef [rifaat.ietf@gmail.com] > *Sent:* Friday, 13 June 2014 8:44 PM > *To:* Peterson, Jon > *Cc:* sipcore@ietf.org; Ivo Sedlacek > *Subject:* Re: [sipcore] SIP OAuth: Information element to carry token > > Hi Jon, > > Yeah, that was my initial reaction to this request, as my intention was > to keep this document aligned with RFC6749. > Personally, I prefer to keep it aligned with RFC6749, but I can kind of > see the argument of using an existing mechanism to keep it aligned with S= IP > in this specific case. > > The challenge-response mechanism defined in RFC2617 is now obsolete; it > is now defined in RFC7235. > The https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in > the process of doing the same for the Digest Scheme. > > The flow in section 4 carries the token in the 200 OK; one possible way > to carry that in SIP is to use the Authentication-Info, which is *not* > part of the challenge-response framework defined in RFC7235. > The Authentication-Info is defined in the above Digest draft, which we > could make sure that it is extendible (I just noticed that it is not exte= ndible > in the current version but I can fix that in the next version of the Dige= st > draft). > That would allow us to extend it for SIP, if that is what we want to do. > > I do not have strong opinion on this one; I can go either way. > > Regards, > Rifaat > > > > On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon > wrote: > >> >> Well, the Authorization header field is defined in RFC2617, and the >> base SIP specification instructs implementers to use its syntax. In othe= r >> words, these headers don't belong to us. The syntax and semantics of OAu= th >> is nothing like them. I don't think it's reasonable for us to just overl= oad >> the syntax and semantics of the HTTP authentication system in this way f= or >> SIP. Nor is it that case that by doing so in SIP, we will allow "any >> protocol that uses these headers" to use OAuth - that's exactly backward= s. >> What we'd be doing is creating fragmentation and confusion. >> >> Our OAuth usage should be aligned with HTTP's usage, that is, with >> RFC6749. If we want something different, I think we need to talk to them >> about it. >> >> Jon Peterson >> Neustar, Inc. >> >> From: Rifaat Shekh-Yusef >> Date: Friday, June 13, 2014 at 5:18 AM >> To: Ivo Sedlacek >> Cc: "sipcore@ietf.org" >> >> Subject: Re: [sipcore] SIP OAuth: Information element to carry token >> >> I am fine with this; I will make the change in the next version of the >> draft. >> >> Regards, >> Rifaat >> >> >> >> On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek >> wrote: >> >>> Hello, >>> >>> >>> >>> I share the same view as Christer. >>> >>> >>> >>> New authentication schemes should preferably extend / re-use the header= s >>> defined for authentication (i.e. WWW-Authenticate, Authorization, >>> Authentication-Info, Proxy-Authenticate, Proxy-Authorization). >>> >>> >>> >>> This would enable usage of the OAuth method in any protocol which uses >>> those headers. >>> >>> >>> >>> This would enable usage of the OAuth method in (a) authentication with >>> proxy and (b) authentication with server. >>> >>> >>> >>> Kind regards >>> >>> >>> >>> Ivo Sedlacek >>> >>> >>> >>> This Communication is Confidential. We only send and receive email on >>> the basis of the terms set out at www.ericsson.com/email_disclaimer >>> >>> >>> *From:* sipcore [mailto:sipcore-bounces@ietf.org >>> ] *On Behalf Of *Rifaat Shekh-Yusef >>> *Sent:* 12. =C4=8Dervna 2014 18:58 >>> *To:* Christer Holmberg >>> *Cc:* sipcore@ietf.org >>> *Subject:* Re: [sipcore] SIP OAuth: Information element to carry token >>> >>> >>> >>> Hi Christer, >>> >>> >>> >>> I tried to keep this proposal aligned with approach taken by RFC6749, >>> but I think that using Authorization header would be a valid option too= . >>> >>> Is there any reason that you prefer it to be carried in the >>> Authorization header instead of the message body? >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>> Hi, >>> >>> >>> >>> I was taking a look at draft-yusef-sipcore-sip-oauth-00. >>> >>> >>> >>> In section 4, I see that the OAuth token is carried in a message body. >>> Is there a reason why one could not use the SIP Authorization header f= ield? >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >>> >> >> > --089e0129538013cd6b04fbf35036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Keith,

Where do you stand on the= se two questions?

Regards,
=C2=A0Rifaat<= /div>



On Sun, Jun 15, 2014 at 4:02 PM, DRAGE, Keith (Keith) <= ;keith.= drage@alcatel-lucent.com> wrote:
I suspect there are two steps to this question.
=C2=A0
1)=C2=A0=C2=A0=C2=A0 Given that there are some differences between HTTP a= nd SIP, would it be more appropriate to use a header field rather than a me= ssage body?
=C2=A0
2)=C2=A0=C2=A0=C2=A0 If a header field is used, should it be an extension= of an existing header field or a new one?
=C2=A0
regards
=C2=A0
Keith

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 14 June 2014 09:32
To: Rifaat Shekh-Yusef; Peterson, Jon

Cc: sipcore@ie= tf.org; Ivo Sedlacek
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

Hi,

=C2=A0

My initial question was why existing SIP header fields weren't used.= IF=C2=A0there=C2=A0are good reasons (e.g. based on Jon's input) I thin= k it would be useful to document those in the draft.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

Fro= m: sipcore [sipcore-bounces@ietf.org] on behalf of Rifaat Shekh-Yusef [rifaat.ietf@gmail.com]
Sent: Friday, 13 June 2014 8:44 PM
To: Peterson, Jon
Cc: sipcore@ie= tf.org; Ivo Sedlacek
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

Hi Jon,

Yeah, that was my initial reaction to this request, as my intention wa= s to keep this document aligned with RFC6749.
Personally, I prefer to keep it align= ed with=C2=A0RFC6749, but I can kind of see the argument of using an= existing mechanism to keep it aligned with SIP in this specific case.

The challenge-response mechanism defined in RFC2617 is now obsolete; i= t is now defined in=C2=A0RFC7235.
The=C2=A0https://data= tracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the process of d= oing the same for the Digest Scheme.

The flow in section 4 carries the tok= en in the 200 OK; one possible way to carry that in SIP is to use the=C2=A0= Authentication-Info, which is not part of the challenge-response framework defined in RFC7235.
The=C2=A0Authentication-Info is defin= ed in the above Digest draft, which we could make sure that it is=C2=A0exte= ndible (I just noticed that it is not=C2=A0extendible in the current version but I can fix that in the next version of the Digest draft).
That would allow us to extend it for = SIP, if that is what we want to do.

I do not have strong opinion on this one; I can go either way.

Regards,
=C2=A0Rifaat



On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon = <jon.peter= son@neustar.biz> wrote:

Well, the Authorization header field is defined in RFC2617, and the ba= se SIP specification instructs implementers to use its syntax. In other wor= ds, these headers don't belong to us. The syntax and semantics of OAuth= is nothing like them. I don't think it's reasonable for us to just overload the syntax and semantics of th= e HTTP authentication system in this way for SIP. =C2=A0Nor is it that case= that by doing so in SIP, we will allow "any protocol that uses these = headers" to use OAuth - that's exactly backwards. What we'd be doing is creating fragmentation and confusion.=C2=A0

Our OAuth usage should be aligned with HTTP's usage, that is, with= RFC6749. If we want something different, I think we need to talk to them a= bout it.

Jon Peterson
Neustar, Inc.


I am fine with this; I will make the change in the next ve= rsion of the draft.

Regards,
=C2=A0Rifaat



On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <ivo.sedl= acek@ericsson.com> wrote:

Hello,

=C2=A0

I share the same view as Christer.

=C2=A0

New authentication schemes should preferably e= xtend / re-use the headers defined for authentication (i.e. WWW-Authenticat= e, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

=C2=A0

This would enable usage of the OAuth method in= any protocol which uses those headers.

=C2=A0

This would enable usage of the OAuth method in= (a) authentication with proxy and (b) authentication with server.

=C2=A0

Kind regards

=C2=A0

Ivo Sedlacek

=C2=A0

This Communication is Confidential. We only send= and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. =C4=8Dervna 2014 18:58
To: Christer Holmberg
Cc: sipcore@ie= tf.org
Subject: Re: [sipcore] SIP OAuth: Information element to carry token=

=C2=A0

Hi Christer,

=C2=A0

I tried to keep this proposal aligned with approach = taken by RFC6749, but I think that using Authorization header would be a va= lid option too.

Is there any reason that you prefer it to be carried= in the Authorization header instead of the message body?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

I was taking a look at draft-yusef-sipcore-sip-oauth-00.

=C2=A0

In section 4, I see that the OAuth token i= s carried in a message body. Is there a reason why=C2=A0one could not use= =C2=A0 the SIP Authorization header field?

=C2=A0

Regards,

=C2=A0

Christer=


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

=C2=A0




--089e0129538013cd6b04fbf35036-- From nobody Mon Jun 16 13:18: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 441301A01E8 for ; Mon, 16 Jun 2014 13:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, TVD_SPACE_RATIO=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 Pyk6kwYBasjl for ; Mon, 16 Jun 2014 13:18: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 3EBED1A01D5 for ; Mon, 16 Jun 2014 13:18:55 -0700 (PDT) Received: from unnumerable.local (pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5GKIruw074078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 16 Jun 2014 15:18:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66] claimed to be unnumerable.local Message-ID: <539F512E.2050207@nostrum.com> Date: Mon, 16 Jun 2014 15:18:54 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/yGaQQV-Aa6T7Gff6OdlTFuidhg0 Subject: [sipcore] draft-sparks-sipcore-refer-clarifications-00 is available 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, 16 Jun 2014 20:18:56 -0000 To continue the conversation started in the London meeting, see RjS From nobody Tue Jun 17 13:22: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 B9CE91A0166 for ; Tue, 17 Jun 2014 13:22:18 -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 8sU-hlohtUuW for ; Tue, 17 Jun 2014 13:22:18 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id C49321A011C for ; Tue, 17 Jun 2014 13:22:17 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id FY6t1o0051ei1Bg51YNHmX; Tue, 17 Jun 2014 20:22:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id FYNH1o00G3ZTu2S3kYNHxl; Tue, 17 Jun 2014 20:22:17 +0000 Message-ID: <53A0A379.5050903@alum.mit.edu> Date: Tue, 17 Jun 2014 16:22: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: sipcore@ietf.org References: <539F512E.2050207@nostrum.com> In-Reply-To: <539F512E.2050207@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=1403036537; bh=kOaZ+tPwHRaON1blEyTrrsHRC9Y2ZpXOVGVXU6vywu0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QtC9s5ViQ/8Xi1sa6oAu7pxcyuhGaZdd1+y+dv1KZy01k1amoqjkQxOlG/wsTmMTd vLsgvW6C1OsnkngUIPl7vT20xOdPFLjkQBqWrAGRQhdzjUhuVGz064J3UqET/kmba8 4/fz5gnGZKDKrQMoWMyiDdbmRoCXp8yheH4+ys1NBsYZMul/6QZkEW+Q6+aop51Tak OOSCJyuDgLJb0VvLJHt1GZ4Yz4JsEmZnonU1Q/+/n5YlSqvM28FFAjxMhBjeQOsVmg JuT48ZB24q0owVMAhwkzLWW0AOnSNTQF/arR3MWL6uqI0/c8Z0lprDOIqIOZIqu7e/ KiyUNbza392Vw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/id8PSi9j-EANJu6if5qlLMfiUUg Subject: Re: [sipcore] draft-sparks-sipcore-refer-clarifications-00 is available 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, 17 Jun 2014 20:22:19 -0000 This draft may or may not meet the expectations of the people who had issues with REFER and 6665. Please be sure to review and raise any issues you may have - either with the correctness of this draft, or its sufficiency. Thanks, Paul On 6/16/14 4:18 PM, Robert Sparks wrote: > To continue the conversation started in the London meeting, see > > > > RjS > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jun 17 14:34: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 7AB4C1A017C for ; Tue, 17 Jun 2014 14:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 DL8g7ISbVTRT for ; Tue, 17 Jun 2014 14:34:23 -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 8EC781A017B for ; Tue, 17 Jun 2014 14:34:23 -0700 (PDT) Received: from unnumerable.local (pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5HLYM0A044499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Tue, 17 Jun 2014 16:34:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66] claimed to be unnumerable.local Message-ID: <53A0B45E.3020909@nostrum.com> Date: Tue, 17 Jun 2014 16:34:22 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sipcore@ietf.org" References: <20140617212748.31334.32062.idtracker@ietfa.amsl.com> In-Reply-To: <20140617212748.31334.32062.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140617212748.31334.32062.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010906020503090200070608" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ucWBkk4uKMERBqpIoGfESGVzxuY Subject: [sipcore] Fwd: New Version Notification for 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, 17 Jun 2014 21:34:25 -0000 This is a multi-part message in MIME format. --------------010906020503090200070608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The other idea we started discussing in London: -------- Original Message -------- Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt Date: Tue, 17 Jun 2014 14:27:48 -0700 From: internet-drafts@ietf.org To: Robert Sparks , "Robert Sparks" A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-00.txt has been successfully submitted by Robert Sparks and posted to the IETF repository. Name: draft-sparks-sipcore-refer-explicit-subscription Revision: 00 Title: Explicit Subscriptions for the REFER Method Document date: 2014-06-17 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-00.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-00 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 --------------010906020503090200070608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit The other idea we started discussing in London:


-------- Original Message --------
Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt
Date: Tue, 17 Jun 2014 14:27:48 -0700
From: internet-drafts@ietf.org
To: Robert Sparks <rjs@nostrum.com>, "Robert Sparks" <RjS@nostrum.com> 


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

Name:		draft-sparks-sipcore-refer-explicit-subscription
Revision:	00
Title:		Explicit Subscriptions for the REFER Method
Document date:	2014-06-17
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-00.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-00


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


--------------010906020503090200070608-- From nobody Fri Jun 20 01:34: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 7B0E21B279E for ; Fri, 20 Jun 2014 01:34:45 -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 qJvw5vZRxa0J for ; Fri, 20 Jun 2014 01:34:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E261AD6B1 for ; Fri, 20 Jun 2014 01:34:38 -0700 (PDT) X-AuditID: c1b4fb2d-f79776d000001085-b3-53a3f21c1a01 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 83.48.04229.C12F3A35; Fri, 20 Jun 2014 10:34:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Fri, 20 Jun 2014 10:34:34 +0200 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt Thread-Index: AQHPinPsKXARpYQS/Ue+yBtdwbAQ1Zt5r4XY Date: Fri, 20 Jun 2014 08:34:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D399481@ESESSMB209.ericsson.se> References: <20140617212748.31334.32062.idtracker@ietfa.amsl.com>, <53A0B45E.3020909@nostrum.com> In-Reply-To: <53A0B45E.3020909@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D399481ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja7Mp8XBBktn8Vtcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvjRNdOtoLbdhV7VzxjbWBcY9rFyMkhIWAi 0bbgLBOELSZx4d56ti5GLg4hgaOMEv8+HmCEcBYxSiz8uBaoioODTcBCovufNkiDiECgxMJJ S1hAbGGBIomOffNZIOLFEpfXX2SGsI0k1q2aBLaARUBV4nHnUbAaXgFfiau/X4DZQgIJEjN2 72UEsTkFtCX+3N0MFmcEOuj7qTVgvcwC4hK3nsyHOlRAYsme88wQtqjEy8f/WEFOkxBQkpi2 NQ2iPF/ix9f77BCrBCVOznzCMoFRZBaSSbOQlM1CUgYR15O4MXUKG4StLbFs4WtmCFtXYsa/ QyzI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbVwS2/dXcwrn7teIhRgINRiYc3 IXZxsBBrYllxZe4hRmkOFiVx3kXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFQqfbgq 6t7piPj8WL6MVabXL8un9aTpK33ZJDFB6+N8a4WPn4V/zGfbOsvi4qqijT8fFcTszNdqqeux VtZZMuXWq+ZVe/c7b6nuS/cXVHjR2/jVyoJvR9eVnfe5GGz7t4mJhvKLNtr15+4+Pn/CZP3t ORJTzmkbzdzG/1K79ZlZaWB9teVDRyWW4oxEQy3mouJEAH/EuDyLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ewQ7UM9JkytftsLX_CJCO4EL1h8 Subject: Re: [sipcore] Fwd: New Version Notification for 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, 20 Jun 2014 08:34:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D399481ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I assume the semantics of the suggested new 'explicitsub' option tag would = be "MUST SUPPORT *AND* MUST USE". (I.e. the option tag can be used to ensure that the receiver will not creat= e a subscription, instead of simply making sure the receiver understands th= e meaning of, and supports the mechanism associated with, the option-tag?) Regards, Christer ________________________________ From: sipcore [sipcore-bounces@ietf.org] on behalf of Robert Sparks [rjspar= ks@nostrum.com] Sent: Wednesday, 18 June 2014 12:34 AM To: sipcore@ietf.org Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-r= efer-explicit-subscription-00.txt The other idea we started discussing in London: -------- Original Message -------- Subject: New Version Notification for draft-sparks-sipcore-refer-exp= licit-subscription-00.txt Date: Tue, 17 Jun 2014 14:27:48 -0700 From: internet-drafts@ietf.org To: Robert Sparks , "Robert Sp= arks" A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-00.t= xt has been successfully submitted by Robert Sparks and posted to the IETF repository. Name: draft-sparks-sipcore-refer-explicit-subscription Revision: 00 Title: Explicit Subscriptions for the REFER Method Document date: 2014-06-17 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-sparks-sipcore-re= fer-explicit-subscription-00.txt Status: https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer= -explicit-subscription/ Htmlized: http://tools.ietf.org/html/draft-sparks-sipcore-refer-expli= cit-subscription-00 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_7594FB04B1934943A5C02806D1A2204B1D399481ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I assume the semantics o= f the suggested new 'explicitsub' option tag would be "= MUST SUPPORT *AND* MUST USE".
 
(I.e. the option tag can= be used to ensure that the receiver will not create a subscription, instea= d of simply making sure the receiver understands the meaning of, and suppor= ts the mechanism associated with, the option-tag?)
 
Regards,
 
Christer
 
From: sipcore [sipcore-bounces@ietf.org] o= n behalf of Robert Sparks [rjsparks@nostrum.com]
Sent: Wednesday, 18 June 2014 12:34 AM
To: sipcore@ietf.org
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-si= pcore-refer-explicit-subscription-00.txt

The other idea we started discussing in London:


-------- Original Message --------
Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscr= iption-00.txt
Date: Tue, 17 Jun 2014 14:27:48 -0700
From: internet-drafts@ietf.org
To: Robert Sparks <rjs@nostrum.com>, "Robert Sparks" <RjS@nostrum.com> 


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

Name:		draft-sparks-sipcore-refer-explicit-subscription
Revision:	00
Title:		Explicit Subscriptions for the REFER Method
Document date:	2014-06-17
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcor=
e-refer-explicit-subscription-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-exp=
licit-subscription/
Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subsc=
ription-00


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.

                                                                           =
      =20


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_7594FB04B1934943A5C02806D1A2204B1D399481ESESSMB209erics_-- From nobody Fri Jun 20 15: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 4BC181A00E8 for ; Fri, 20 Jun 2014 15:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hZxnGV8_l6c0 for ; Fri, 20 Jun 2014 15:12:17 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E10D1A02CA for ; Fri, 20 Jun 2014 15:12:17 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id Gm5G1o0021ei1Bg5AmCGz0; Fri, 20 Jun 2014 22:12:16 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta24.westchester.pa.mail.comcast.net with comcast id GmCG1o00F1KKtkw3kmCGyx; Fri, 20 Jun 2014 22:12:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s5KMCGDO021822; Fri, 20 Jun 2014 18:12:16 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s5KMCGEE021821; Fri, 20 Jun 2014 18:12:16 -0400 Date: Fri, 20 Jun 2014 18:12:16 -0400 Message-Id: <201406202212.s5KMCGEE021821@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: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D37208F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B1EDA28@FR712WXCHMBA11.zeu.alcatel-lucent.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403302337; bh=b2vMbDpb0op+Wn9eQOYmDU+WN8XD5RJrcGTva1bOS3M=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=qf8wn/2eRFypax0hcImPwvrRhuOJgS+wBKOUTBYq/j1KK9G8LtrnBD7I1zlkiP3Kc MADWeZApgPnUazvNr8ozs8vL+ATmrweogQxvy2NK4LM0DPBem0SyazcbeqvmMODnxi nEIXWw4htF1eppY6nBj6ZklLYf1w6QVok0nwhtcb4aqW8581RsFtfjw/MdtrpXLMRI K6BxXhqy6cof7Rz5AAcY/FmfvM/cyzMC6jSjgK/rtUNQ+4xietXDlHzmSrPDbdP0WR xl8ruqnTU2yW+hIqKfV2/CL5ZRVjDUzVdmPPZLAGleCKKtzApDJ3EyDgPmHCscPE4G x4mn8Gg85Sm/A== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/c5zMgATuILmODkhBo3u1vHu03aQ Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 20 Jun 2014 22:12:23 -0000 Perhaps it's because I've not read the draft closely enough, but it seems like there isn't a statement of: - What precisely is the mechanism intended to achieve? - How does it relate to OAuth itself? As far as I can tell from the OAuth documents, OAuth is to permit a "client" (a third-party application) to access a protected resource on a "resource server" without requiring the ultimate "user" (on whose behalf the client is operating) to give the client a copy of the user's credentials. But while the SIP proxy is designated as having the "resource server" role, it's not clear to me who the OAuth "client" is. Is it the same as the SIP client? (If so, then why bother with the OAuth overhead, as the "client" then *always* knows the user's credentials?) Dale From nobody Sat Jun 21 04:33: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 968BC1B2A41 for ; Sat, 21 Jun 2014 04:33:15 -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 IXtg5t_VUxYZ for ; Sat, 21 Jun 2014 04:33:14 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001: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 D6AF31B2A40 for ; Sat, 21 Jun 2014 04:33:13 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so4160955ieb.36 for ; Sat, 21 Jun 2014 04:33:13 -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=ggX6Md9gAKy2KSU6AS4Fsdu8RubefDj6OlG6EDo7RRc=; b=1J+efKIeUDwGqvSYvYIRM5ceIe4stG4g7dkCCovQzYKk8dYFeTRTt+e/Bja1T1y8m5 HcC4QfRpyD32uzbeJyDp8OUTC1T2yoMW5qmHwU9zCDc+MhWCf+5XuuGRNDD45oCqi/Dk w/6Je3HsXJjAWIc9kF+8mMICIgEwEIz5JTm8LpPD6GFS2IFlmWSjaT7BLnit7FwHq9Ow xWS9at4ew+DQfJpyApmFIMIq6T+uEuAwH1h6gxUz+VrNC+Eo0VsmjjCQTbZ6xTXuJHO+ wnG3gyXa00nSRmzubvhyWVtOf1kFFQjc9cnArdUQMc5mS5kwF/MGcR9TX1+3Tzui7+xS wTVQ== MIME-Version: 1.0 X-Received: by 10.43.154.207 with SMTP id lf15mr1120182icc.92.1403350392720; Sat, 21 Jun 2014 04:33:12 -0700 (PDT) Received: by 10.50.114.97 with HTTP; Sat, 21 Jun 2014 04:33:12 -0700 (PDT) In-Reply-To: <201406202212.s5KMCGEE021821@hobgoblin.ariadne.com> References: <7594FB04B1934943A5C02806D1A2204B1D35F7BC@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126E788A@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D37208F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B1EDA28@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201406202212.s5KMCGEE021821@hobgoblin.ariadne.com> Date: Sat, 21 Jun 2014 07:33:12 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c2de94a7529004fc56f9ad Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/STHOej48M59IwdygzWJYsfdBpdk Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OAuth: Information element to carry token 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, 21 Jun 2014 11:33:15 -0000 --001a11c2de94a7529004fc56f9ad Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, Thanks for the review and comments. Please, see my reply inline... Regards, Rifaat On Fri, Jun 20, 2014 at 6:12 PM, Dale R. Worley wrote: > Perhaps it's because I've not read the draft closely enough, but it > seems like there isn't a statement of: > > - What precisely is the mechanism intended to achieve? > > I touched on this in the introduction section: This document defines a new authorization mechanism for SIP that is based on the OAuth 2.0 protocol. The new mechanism allows the proxy to avoid challenging every request from the client. The use of tokens is a Single Sing-On enabler, which allows for the definition of fine grained scopes that could be used by proxies and application servers to authorize clients to perform certain actions of behalf of the user but not others. I will try to expand on this in the next version of the draft. > - How does it relate to OAuth itself? > > As far as I can tell from the OAuth documents, OAuth is to permit a > "client" (a third-party application) to access a protected resource on > a "resource server" without requiring the ultimate "user" (on whose > behalf the client is operating) to give the client a copy of the > user's credentials. > > But while the SIP proxy is designated as having the "resource server" > role, it's not clear to me who the OAuth "client" is. Is it the same > as the SIP client? (If so, then why bother with the OAuth overhead, > as the "client" then *always* knows the user's credentials?) > > The Resource Server could be an outbound proxy or an application server that provides some service. The Client could be the SIP UA or the outbound proxy trying to get access to some application server. While in the case when the UA is the Client, the UA will have access to the credentials, the new mechanism has the following benefits: 1. The proxy does not have to challenge every request from the UA 2. The token could be used by the system to control access to other services, and to control the level of service provided by an application. I will try to spin a new draft and include more details about the use cases and the benefits of this mechanism. Regards, Rifaat > Dale > --001a11c2de94a7529004fc56f9ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dale,

Thanks for the revi= ew and comments.
Please, see my reply inline...
<= div>
Regards,
=A0Rifaat


On Fri,= Jun 20, 2014 at 6:12 PM, Dale R. Worley <worley@ariadne.com> wrote:
Perhaps it's because I've not read the draft close= ly enough, but it
seems like there isn't a statement of:

- What precisely is the mechanism intended to achieve?


I touched on this in the int= roduction section:

   This document defines a=
 new authorization mechanism for SIP that is
   based on the OAuth 2.0 protocol. The new mechanism allows the proxy
   to avoid challenging every request from the client. The use of tokens
   is a Single Sing-On enabler, which allows for the definition of fine
   grained scopes that could be used by proxies and application servers
   to authorize clients to perform certain actions of behalf of the user
   but not others.
=A0I will try to expand on this in the next version of the= draft.

=A0
- How does it relate to OAuth itself?

As far as I can tell from the OAuth documents, OAuth is to permit a
"client" (a third-party application) to access a protected resour= ce on
a "resource server" without requiring the ultimate "user&quo= t; (on whose
behalf the client is operating) to give the client a copy of the
user's credentials.

But while the SIP proxy is designated as = having the "resource server"
role, it's not clear to me who the OAuth "client" is. =A0Is i= t the same
as the SIP client? =A0(If so, then why bother with the OAuth overhead,
as the "client" then *always* knows the user's credentials?)<= br>

The Resource Server could be an outbound proxy or an application serv= er that provides some service.
The Client could be the SIP UA or = the outbound proxy trying to get access to some application server.

While in the case when the UA is the Client, the UA wil= l have access to the credentials, the new mechanism has the following benef= its:
1. The proxy does not have to challenge every request from t= he UA
2. The=A0t= oken could be used by the system to control access to other services, and t= o control the level of service provided by an application.


I will try to spin a new draft and include mo= re details about the use cases and the benefits of this mechanism.

Regards,
=A0Rifaat

= =A0
Dale

--001a11c2de94a7529004fc56f9ad-- From nobody Mon Jun 23 03: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 8D3C21B2900 for ; Mon, 23 Jun 2014 03:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 qVbAldCj0YC3 for ; Mon, 23 Jun 2014 03:55:09 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C351B28F7 for ; Mon, 23 Jun 2014 03:55:09 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id i13so5957548veh.29 for ; Mon, 23 Jun 2014 03:55:08 -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=SmXcGmj+lyWDtoLf1/jAKHjL67Wt+EMct03yO3PIFfo=; b=CK6KbA1h4Nw4Id8b5lfEgVAdf5ijvx9W14dTrH7KXT4jE10M7UW3/BYEKklGP7mzvR q7gv57PASbrDjmzmQFKdSQm9roAFEaYPzFPPrYXdvSxIWHrV7UsEAHBDIPVlM+khe9DX wJryuNVcXC4qH5vYUdIfhwb+g7cREVpCSLUtGZddc9/EkR6zrb659GRHRwvBkCuUJBy+ 4J0ZBp33bMlYV6uH7cZuYRwQjYTjpOeBm3gMPwBC2s1VHeCbFlUlDd+RXhfVzfb33CR/ YhHwidkGBLOwxPrlcowZksOIXfmHdtIt3C5563p1j6YUxvZtWodUp6NKDHaxBDWHLnNL +8aA== X-Gm-Message-State: ALoCoQnhiSqoqrUeAw7FgFb1wVrtUxTjeMfw/WQxulgfncvhrEJ4T5Yudq2ZZBr75zO2cVul5qzS X-Received: by 10.58.216.4 with SMTP id om4mr25939vec.66.1403520908563; Mon, 23 Jun 2014 03:55:08 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+O0ZlDoxNxnt65QYWSzxF8igw1gA== Date: Mon, 23 Jun 2014 06:55:08 -0400 Message-ID: <43050c7cdd82884d0e44ac7c97bfcb83@mail.gmail.com> To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ukAQiSULikeYqV9ouNFyfmndINQ Subject: [sipcore] RFC 6026: timer to use to avoid being stuck within Proceeding 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, 23 Jun 2014 10:55:14 -0000 Hi, A RFC 6026 thread on sip-implementors raises a question concerning what timer(s) were expected to be used to eventually allow the transition from Proceeding to Terminated when stuck in Proceeding because of the RFC 6026 requirement to remain in the current state during non-recoverable transport error situations. Within the following paragraph, was a proprietary timer expected to be used while within Proceeding? If not, what RFC defined timer was expected to be used? "A server transaction MUST NOT discard transaction state based only on encountering a non-recoverable transport error when sending a response. Instead, the associated INVITE server transaction state machine MUST remain in its current state. (Timers will eventually cause it to transition to the "Terminated" state). This allows retransmissions of the INVITE to be absorbed instead of being processed as a new request." Thanks, Brett From nobody Mon Jun 23 06:57:22 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 8F0811B2AE7 for ; Mon, 23 Jun 2014 06:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, 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 VzaCzJuAW_KA for ; Mon, 23 Jun 2014 06:57:18 -0700 (PDT) Received: from mail-wg0-f43.google.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with SMTP id 43BCC1B2929 for ; Mon, 23 Jun 2014 06:57:18 -0700 (PDT) Received: from mail-wg0-f43.google.com ([74.125.82.43]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKU6gyPPpWBCodCKpJWnpaY88MqehWwsUp@postini.com; Mon, 23 Jun 2014 06:57:18 PDT Received: by mail-wg0-f43.google.com with SMTP id b13so6308000wgh.2 for ; Mon, 23 Jun 2014 06:57:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v1TZDAT8I/4G/SpCE0PNzD44vckmpoYcTVkM8B1T4OA=; b=YmktD0J6vbraAMyuxU7OQndG150qsoPgIGlvRg8iVjI0b/3xeB+crLYlBhCrspuCkr y8HrVjNWb8YYy0we38Se7SZqthHJiITTvl23h/sEg+4jVBLYwSVpWqsSclcvBcCUS9iU XlMeWUCxrZvdQMAR8fwtNEFP6k2HxrbXZBpakaEhw0RBQCoC7iA6cObPF3GbTUW6iS/y TFKIQoPeF3yMgALjj2d9BlDCVndDbFcnJuaQw7/L9F6Af/ykBweNqJuF+YaubWW/8dZy bQR8RtIjCUebcj7hyOOFiDhbf6uz4EIbGX6vZcbdtMtPgo+i44OM80mFODjIwjTg9ilc 51gg== X-Gm-Message-State: ALoCoQlXqZY9ub+T3Gq2Sy4jC2or+zNSzqI/3x11UU5I2H5j2hchOX5GpMLUnR6DhufvALzCs3ilYJm+ippbnAg/DFqAA2JuyW3AhFMQh0o3r4dwZkRW7/FKiUxD+Crs8AGZIe53Gr7l X-Received: by 10.194.219.70 with SMTP id pm6mr27561695wjc.53.1403531835882; Mon, 23 Jun 2014 06:57:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.219.70 with SMTP id pm6mr27561535wjc.53.1403531834608; Mon, 23 Jun 2014 06:57:14 -0700 (PDT) Received: by 10.194.190.8 with HTTP; Mon, 23 Jun 2014 06:57:14 -0700 (PDT) In-Reply-To: <43050c7cdd82884d0e44ac7c97bfcb83@mail.gmail.com> References: <43050c7cdd82884d0e44ac7c97bfcb83@mail.gmail.com> Date: Mon, 23 Jun 2014 14:57:14 +0100 Message-ID: From: Michael Procter To: Brett Tate Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/pF53vjiRi2P5qv0pS7odxelvGNs Cc: SIPCORE Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck within Proceeding 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, 23 Jun 2014 13:57:20 -0000 My recollection is that the only way for the IST to leave "Proceeding" is to receive a final response from the Transaction User. Once a final response is received, the remaining transitions to "Terminated" are guarded by timers H, I, and L. I'm not aware of a timer guarding the final response from the TU, except for one requested in an Expires header. I think it is probably reasonable to assume that the transaction layer and transaction user are sufficiently closely coupled that they communicate reliably and so don't need a timer. If an implementation can't make that assumption, then I think timer C is probably morally acceptable since it guards a similar condition for proxies. Regards, Michael On 23 June 2014 11:55, Brett Tate wrote: > Hi, > > A RFC 6026 thread on sip-implementors raises a question concerning what > timer(s) were expected to be used to eventually allow the transition from > Proceeding to Terminated when stuck in Proceeding because of the RFC 6026 > requirement to remain in the current state during non-recoverable > transport error situations. Within the following paragraph, was a > proprietary timer expected to be used while within Proceeding? If not, > what RFC defined timer was expected to be used? > > "A server transaction MUST NOT discard transaction state based only on > encountering a non-recoverable transport error when sending a > response. Instead, the associated INVITE server transaction state > machine MUST remain in its current state. (Timers will eventually > cause it to transition to the "Terminated" state). This allows > retransmissions of the INVITE to be absorbed instead of being > processed as a new request." > > Thanks, > Brett > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jun 23 16:04: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 6E47F1A03B4 for ; Mon, 23 Jun 2014 16:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651] 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 fcCI9e3miSE1 for ; Mon, 23 Jun 2014 16:04:33 -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 2AEC91A03A4 for ; Mon, 23 Jun 2014 16:04:33 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5NN4WKB064806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 23 Jun 2014 18:04:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53A8B280.8050305@nostrum.com> Date: Mon, 23 Jun 2014 18:04:32 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <43050c7cdd82884d0e44ac7c97bfcb83@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/sM9xD74kupTNaQBeM5ijr1QQv9g Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck within Proceeding 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, 23 Jun 2014 23:04:36 -0000 Just to make sure folks aren't misreading one thing - you would only remain in the proceeding state while the TU has only handed you 1xx responses (or no response at all). Even if there were transport errors, if the TU hands you a 2xx, you will transition to Accepted (and possibly spin there for a bit if trying to send the 2xx causes a transport error), or to Completed for 300 and greater responses. Timers in the INVITE server state machine will drain you out of Accepted or Completed. Nothing drains you from proceeding because Invite transactions are designed to be able to pend forever. What will take you out of that state is either the peer changing the state (such as with a CANCEL), or the TU handing down a final response. And the TU is the thing that needs to make the decision on the final response. It's what knows enough to clean up application state if it decides to give up on a long pending transaction. RjS On 6/23/14, 8:57 AM, Michael Procter wrote: > My recollection is that the only way for the IST to leave "Proceeding" > is to receive a final response from the Transaction User. Once a > final response is received, the remaining transitions to "Terminated" > are guarded by timers H, I, and L. > > I'm not aware of a timer guarding the final response from the TU, > except for one requested in an Expires header. I think it is probably > reasonable to assume that the transaction layer and transaction user > are sufficiently closely coupled that they communicate reliably and so > don't need a timer. If an implementation can't make that assumption, > then I think timer C is probably morally acceptable since it guards a > similar condition for proxies. > > Regards, > > Michael > > On 23 June 2014 11:55, Brett Tate wrote: >> Hi, >> >> A RFC 6026 thread on sip-implementors raises a question concerning what >> timer(s) were expected to be used to eventually allow the transition from >> Proceeding to Terminated when stuck in Proceeding because of the RFC 6026 >> requirement to remain in the current state during non-recoverable >> transport error situations. Within the following paragraph, was a >> proprietary timer expected to be used while within Proceeding? If not, >> what RFC defined timer was expected to be used? >> >> "A server transaction MUST NOT discard transaction state based only on >> encountering a non-recoverable transport error when sending a >> response. Instead, the associated INVITE server transaction state >> machine MUST remain in its current state. (Timers will eventually >> cause it to transition to the "Terminated" state). This allows >> retransmissions of the INVITE to be absorbed instead of being >> processed as a new request." >> >> Thanks, >> Brett >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jun 23 20:08: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 897C21B2817 for ; Mon, 23 Jun 2014 20:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 6VYrJa52EMgg for ; Mon, 23 Jun 2014 20:07:58 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c: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 2402C1B2806 for ; Mon, 23 Jun 2014 20:07:57 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so8067386wes.30 for ; Mon, 23 Jun 2014 20:07:56 -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=pVR+cRnUJPyOP7mKMVV58klRJs8KuIzhjEnY+PT6NBM=; b=n3Icj2GaUMBi8ft+7EDTt0lFe6olmI9krHFY4xzJ7u805iJzjIZ5023gZvA68Ie8qZ /GV6oRUnfINs34hGCtT5a10Lw5KGYvrG/o+KmDCqlZdx9qXLu2GLP8HwBs9NxfLpBzgW 9JgyTYNQpicFbBMkDcvuszumqmOyH8mLpfliU5TQX/6hZ8SGHmMrfJNoCnAnE7MM22Wp 8ThEJUaOSCMSXbyT7FaL9cnBVGZJ7a/PjFCuaGa49WCoIFjEuiUdHiwnGVInyFhllROZ BvjZ9hyGUPxS5CqB61nxeqWWKmD72WGL+I1Dn2hrGkO5aQ8/gDizKrwJbzzm2Jl1+zrf FSiQ== MIME-Version: 1.0 X-Received: by 10.194.85.225 with SMTP id k1mr32507149wjz.49.1403579276756; Mon, 23 Jun 2014 20:07:56 -0700 (PDT) Received: by 10.194.59.18 with HTTP; Mon, 23 Jun 2014 20:07:56 -0700 (PDT) In-Reply-To: <53A8B280.8050305@nostrum.com> References: <43050c7cdd82884d0e44ac7c97bfcb83@mail.gmail.com> <53A8B280.8050305@nostrum.com> Date: Tue, 24 Jun 2014 11:07:56 +0800 Message-ID: From: Caixia Liu To: Robert Sparks Content-Type: multipart/alternative; boundary=089e010d8626348b7004fc8c4405 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/z2JXWtarUkeU0Dott8uZrzoSYSY Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck within Proceeding 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, 24 Jun 2014 03:08:05 -0000 --089e010d8626348b7004fc8c4405 Content-Type: text/plain; charset=UTF-8 Thanks a lot for your clarification. I got the idea. When TU hands a response to server transaction, server transaction should transition the state according to the response immediately no matter whether we might run into a transport error or not. Best Regards, Caixia On Tue, Jun 24, 2014 at 7:04 AM, Robert Sparks wrote: > Just to make sure folks aren't misreading one thing - you would > only remain in the proceeding state while the TU has only handed you > 1xx responses (or no response at all). Even if there were transport > errors, if the TU hands you a 2xx, you will transition to Accepted > (and possibly spin there for a bit if trying to send the 2xx causes > a transport error), or to Completed for 300 and greater responses. > Timers in the INVITE server state machine will drain you out of Accepted > or Completed. > > Nothing drains you from proceeding because Invite transactions > are designed to be able to pend forever. What will take you out of that > state is either the peer changing the state (such as with a CANCEL), or > the TU handing down a final response. > > And the TU is the thing that needs to make the decision on the final > response. It's what knows enough to clean up application state if it > decides to give up on a long pending transaction. > > RjS > > > On 6/23/14, 8:57 AM, Michael Procter wrote: > >> My recollection is that the only way for the IST to leave "Proceeding" >> is to receive a final response from the Transaction User. Once a >> final response is received, the remaining transitions to "Terminated" >> are guarded by timers H, I, and L. >> >> I'm not aware of a timer guarding the final response from the TU, >> except for one requested in an Expires header. I think it is probably >> reasonable to assume that the transaction layer and transaction user >> are sufficiently closely coupled that they communicate reliably and so >> don't need a timer. If an implementation can't make that assumption, >> then I think timer C is probably morally acceptable since it guards a >> similar condition for proxies. >> >> Regards, >> >> Michael >> >> On 23 June 2014 11:55, Brett Tate wrote: >> >>> Hi, >>> >>> A RFC 6026 thread on sip-implementors raises a question concerning what >>> timer(s) were expected to be used to eventually allow the transition from >>> Proceeding to Terminated when stuck in Proceeding because of the RFC 6026 >>> requirement to remain in the current state during non-recoverable >>> transport error situations. Within the following paragraph, was a >>> proprietary timer expected to be used while within Proceeding? If not, >>> what RFC defined timer was expected to be used? >>> >>> "A server transaction MUST NOT discard transaction state based only on >>> encountering a non-recoverable transport error when sending a >>> response. Instead, the associated INVITE server transaction state >>> machine MUST remain in its current state. (Timers will eventually >>> cause it to transition to the "Terminated" state). This allows >>> retransmissions of the INVITE to be absorbed instead of being >>> processed as a new request." >>> >>> Thanks, >>> Brett >>> >>> _______________________________________________ >>> 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 > --089e010d8626348b7004fc8c4405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks a lot for your clarification.
I got the idea. When TU hands a response to server transaction, serv= er transaction should transition the state according to the response immedi= ately no matter whether we might run into a transport error or not.

Best Regards,
Caixia

<= /div>


On= Tue, Jun 24, 2014 at 7:04 AM, Robert Sparks <rjsparks@nostrum.com= > wrote:
Just to make sure folks aren't misreadin= g one thing - you would
only remain in the proceeding state while the TU has only handed you
1xx responses (or no response at all). Even if there were transport
errors, if the TU hands you a 2xx, you will transition to Accepted
(and possibly spin there for a bit if trying to send the 2xx causes
a transport error), or to Completed for 300 and greater responses.
Timers in the INVITE server state machine will drain you out of Accepted or Completed.

Nothing drains you from proceeding because Invite transactions
are designed to be able to pend forever. What will take you out of that
state is either the peer changing the state (such as with a CANCEL), or
the TU handing down a final response.

And the TU is the thing that needs to make the decision on the final
response. It's what knows enough to clean up application state if it decides to give up on a long pending transaction.

RjS


On 6/23/14, 8:57 AM, Michael Procter wrote:
My recollection is that the only way for the IST to leave "Proceeding&= quot;
is to receive a final response from the Transaction User. =C2=A0Once a
final response is received, the remaining transitions to "Terminated&q= uot;
are guarded by timers H, I, and L.

I'm not aware of a timer guarding the final response from the TU,
except for one requested in an Expires header. =C2=A0I think it is probably=
reasonable to assume that the transaction layer and transaction user
are sufficiently closely coupled that they communicate reliably and so
don't need a timer. =C2=A0If an implementation can't make that assu= mption,
then I think timer C is probably morally acceptable since it guards a
similar condition for proxies.

Regards,

Michael

On 23 June 2014 11:55, Brett Tate <brett@broadsoft.com> wrote:
Hi,

A RFC 6026 thread on sip-implementors raises a question concerning what
timer(s) were expected to be used to eventually allow the transition from Proceeding to Terminated when stuck in Proceeding because of the RFC 6026 requirement to remain in the current state during non-recoverable
transport error situations. =C2=A0Within the following paragraph, was a
proprietary timer expected to be used while within Proceeding? =C2=A0If not= ,
what RFC defined timer was expected to be used?

"A server transaction MUST NOT discard transaction state based only on=
=C2=A0 encountering a non-recoverable transport error when sending a
=C2=A0 response. =C2=A0Instead, the associated INVITE server transaction st= ate
=C2=A0 machine MUST remain in its current state. =C2=A0(Timers will eventua= lly
=C2=A0 cause it to transition to the "Terminated" state). =C2=A0T= his allows
=C2=A0 retransmissions of the INVITE to be absorbed instead of being
=C2=A0 processed as a new request."

Thanks,
Brett

_______________________________________________
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

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

--089e010d8626348b7004fc8c4405-- From nobody Tue Jun 24 03:37:51 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 941E81B28BE for ; Tue, 24 Jun 2014 03:37:48 -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 a1Savn_uYDnd for ; Tue, 24 Jun 2014 03:37:46 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7B91B28BC for ; Tue, 24 Jun 2014 03:37:46 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db11so86073veb.12 for ; Tue, 24 Jun 2014 03:37:45 -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=KEfMbaL2VD4fxGwxAx15a0sIM3nf/opmuuy23NUy3Jg=; b=YtlB6uRNEt8vHlRa7DshyLU/Ph+zW26TX7SpE5l8m3M8gyfA7gTIQwFfadCXoRLZvY k7QfV4urTI/S6A5U5Orenkd2Htv52ERDc9wPUtIpgd+2f6WdkYwyh51fhHvJdRvyZDhQ dYYJEpLUVgK5VZ4HaH17K3bHolC53yAWo0ck1WhrV1c2W7kY4hbcTuAgsbNqIiCZ8aKs oWZiMw4b3Ub/SstAijq6MhUJrNEZwmUA80/U+WHZsLM0E3FrWIbqaoKaaFv1bbfnqcrV 0GproFpbj34onyLXg5fVjFpRxITKOx568loU0sbw2C47Con1OTL3cNQbYdHEoYddFFVn ZvvQ== X-Gm-Message-State: ALoCoQkQM26S+NGYp117QM2+UxIYu9KHSpjA4OLUJhROny/3f3oZlkZqdIjxkOhFAnZ9swN4pzbq X-Received: by 10.220.122.132 with SMTP id l4mr2297908vcr.41.1403606265489; Tue, 24 Jun 2014 03:37:45 -0700 (PDT) From: Brett Tate References: <43050c7cdd82884d0e44ac7c97bfcb83@mail.gmail.com> <53A8B280.8050305@nostrum.com> In-Reply-To: <53A8B280.8050305@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+PN4Xug8xmrBxcQ3mpidiXV8O8AgAW+FfQ Date: Tue, 24 Jun 2014 06:37:45 -0400 Message-ID: <685a49d7d085fc768c733a2b7ab62eb9@mail.gmail.com> To: Robert Sparks , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/d2nfo1IkqKJvHvxjPytY6k1Tq_c Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck within Proceeding 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, 24 Jun 2014 10:37:48 -0000 Thanks for the clarification. So that I can refer to it in the future, what supports this interpretation? The server diagrams support remaining within proceeding state unless you assume that the Transport Error arrow excludes the sending of anything which might cause a state transition (or are the second phase of another arrow). Similarly the following paragraph requires the reader to assume that "MUST remain in its current state" excludes the sending of anything which might cause a state transition (or are the second phase of sending something which may or may not have already caused a state transition). "A server transaction MUST NOT discard transaction state based only on encountering a non-recoverable transport error when sending a response. Instead, the associated INVITE server transaction state machine MUST remain in its current state. (Timers will eventually cause it to transition to the "Terminated" state). This allows retransmissions of the INVITE to be absorbed instead of being processed as a new request." > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert > Sparks > Sent: Monday, June 23, 2014 7:05 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck > within Proceeding > > Just to make sure folks aren't misreading one thing - you would > only remain in the proceeding state while the TU has only handed you > 1xx responses (or no response at all). Even if there were transport > errors, if the TU hands you a 2xx, you will transition to Accepted > (and possibly spin there for a bit if trying to send the 2xx causes > a transport error), or to Completed for 300 and greater responses. > Timers in the INVITE server state machine will drain you out of > Accepted > or Completed. > > Nothing drains you from proceeding because Invite transactions > are designed to be able to pend forever. What will take you out of that > state is either the peer changing the state (such as with a CANCEL), or > the TU handing down a final response. > > And the TU is the thing that needs to make the decision on the final > response. It's what knows enough to clean up application state if it > decides to give up on a long pending transaction. > > RjS > > On 6/23/14, 8:57 AM, Michael Procter wrote: > > My recollection is that the only way for the IST to leave > "Proceeding" > > is to receive a final response from the Transaction User. Once a > > final response is received, the remaining transitions to "Terminated" > > are guarded by timers H, I, and L. > > > > I'm not aware of a timer guarding the final response from the TU, > > except for one requested in an Expires header. I think it is > probably > > reasonable to assume that the transaction layer and transaction user > > are sufficiently closely coupled that they communicate reliably and > so > > don't need a timer. If an implementation can't make that assumption, > > then I think timer C is probably morally acceptable since it guards a > > similar condition for proxies. > > > > Regards, > > > > Michael > > > > On 23 June 2014 11:55, Brett Tate wrote: > >> Hi, > >> > >> A RFC 6026 thread on sip-implementors raises a question concerning > what > >> timer(s) were expected to be used to eventually allow the transition > from > >> Proceeding to Terminated when stuck in Proceeding because of the RFC > 6026 > >> requirement to remain in the current state during non-recoverable > >> transport error situations. Within the following paragraph, was a > >> proprietary timer expected to be used while within Proceeding? If > not, > >> what RFC defined timer was expected to be used? > >> > >> "A server transaction MUST NOT discard transaction state based only > on > >> encountering a non-recoverable transport error when sending a > >> response. Instead, the associated INVITE server transaction state > >> machine MUST remain in its current state. (Timers will eventually > >> cause it to transition to the "Terminated" state). This allows > >> retransmissions of the INVITE to be absorbed instead of being > >> processed as a new request." > >> > >> Thanks, > >> Brett > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 24 05:58: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 C0EE41B290E for ; Tue, 24 Jun 2014 05:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 B9SzwAZjndvz for ; Tue, 24 Jun 2014 05:58:26 -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 7F2221B2908 for ; Tue, 24 Jun 2014 05:58:26 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5OCwN9V046739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 24 Jun 2014 07:58:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53A975EF.5020005@nostrum.com> Date: Tue, 24 Jun 2014 07:58:23 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brett Tate , sipcore@ietf.org References: <43050c7cdd82884d0e44ac7c97bfcb83@mail.gmail.com> <53A8B280.8050305@nostrum.com> <685a49d7d085fc768c733a2b7ab62eb9@mail.gmail.com> In-Reply-To: <685a49d7d085fc768c733a2b7ab62eb9@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------020106040500040508020400" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Wfs9W9khkM3YI62MLytXUmD9-io Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck within Proceeding 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, 24 Jun 2014 12:58:32 -0000 This is a multi-part message in MIME format. --------------020106040500040508020400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/24/14, 5:37 AM, Brett Tate wrote: > Thanks for the clarification. So that I can refer to it in the future, > what supports this interpretation? > > The server diagrams support remaining within proceeding state unless you > assume that the Transport Error arrow excludes the sending of anything > which might cause a state transition (or are the second phase of another > arrow). Similarly the following paragraph requires the reader to assume > that "MUST remain in its current state" excludes the sending of anything > which might cause a state transition (or are the second phase of sending > something which may or may not have already caused a state transition). > > "A server transaction MUST NOT discard transaction state based only on > encountering a non-recoverable transport error when sending a > response. Instead, the associated INVITE server transaction state > machine MUST remain in its current state. (Timers will eventually > cause it to transition to the "Terminated" state). This allows > retransmissions of the INVITE to be absorbed instead of being > processed as a new request." I think you've become confused about what the transition conditions say. I think you're trying to read "send response" as "successfully sent response". It just means that you passed it to the transport layer, which may come back and say it had trouble later. (Search for "MUST be passed to the transport layer" in RFC3261.) The thing you should point to is the second paragraph of 7.1: " If the SIP element's TU (Transaction User) issues a 2xx response for this transaction while the state machine is in the "Proceeding" state, the state machine MUST transition to the "Accepted" state and set Timer L to 64*T1, where T1 is the round-trip time estimate defined in Section 17.1.1.1 of [RFC3261]." and the corresponding language for 3xx-6xx in RFC3261. > > >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert >> Sparks >> Sent: Monday, June 23, 2014 7:05 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck >> within Proceeding >> >> Just to make sure folks aren't misreading one thing - you would >> only remain in the proceeding state while the TU has only handed you >> 1xx responses (or no response at all). Even if there were transport >> errors, if the TU hands you a 2xx, you will transition to Accepted >> (and possibly spin there for a bit if trying to send the 2xx causes >> a transport error), or to Completed for 300 and greater responses. >> Timers in the INVITE server state machine will drain you out of >> Accepted >> or Completed. >> >> Nothing drains you from proceeding because Invite transactions >> are designed to be able to pend forever. What will take you out of that >> state is either the peer changing the state (such as with a CANCEL), or >> the TU handing down a final response. >> >> And the TU is the thing that needs to make the decision on the final >> response. It's what knows enough to clean up application state if it >> decides to give up on a long pending transaction. >> >> RjS >> >> On 6/23/14, 8:57 AM, Michael Procter wrote: >>> My recollection is that the only way for the IST to leave >> "Proceeding" >>> is to receive a final response from the Transaction User. Once a >>> final response is received, the remaining transitions to "Terminated" >>> are guarded by timers H, I, and L. >>> >>> I'm not aware of a timer guarding the final response from the TU, >>> except for one requested in an Expires header. I think it is >> probably >>> reasonable to assume that the transaction layer and transaction user >>> are sufficiently closely coupled that they communicate reliably and >> so >>> don't need a timer. If an implementation can't make that assumption, >>> then I think timer C is probably morally acceptable since it guards a >>> similar condition for proxies. >>> >>> Regards, >>> >>> Michael >>> >>> On 23 June 2014 11:55, Brett Tate wrote: >>>> Hi, >>>> >>>> A RFC 6026 thread on sip-implementors raises a question concerning >> what >>>> timer(s) were expected to be used to eventually allow the transition >> from >>>> Proceeding to Terminated when stuck in Proceeding because of the RFC >> 6026 >>>> requirement to remain in the current state during non-recoverable >>>> transport error situations. Within the following paragraph, was a >>>> proprietary timer expected to be used while within Proceeding? If >> not, >>>> what RFC defined timer was expected to be used? >>>> >>>> "A server transaction MUST NOT discard transaction state based only >> on >>>> encountering a non-recoverable transport error when sending a >>>> response. Instead, the associated INVITE server transaction state >>>> machine MUST remain in its current state. (Timers will eventually >>>> cause it to transition to the "Terminated" state). This allows >>>> retransmissions of the INVITE to be absorbed instead of being >>>> processed as a new request." >>>> >>>> Thanks, >>>> Brett >>>> >>>> _______________________________________________ >>>> 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 --------------020106040500040508020400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 6/24/14, 5:37 AM, Brett Tate wrote:
Thanks for the clarification.  So that I can refer to it in the future,
what supports this interpretation?

The server diagrams support remaining within proceeding state unless you
assume that the Transport Error arrow excludes the sending of anything
which might cause a state transition (or are the second phase of another
arrow).  Similarly the following paragraph requires the reader to assume
that "MUST remain in its current state" excludes the sending of anything
which might cause a state transition (or are the second phase of sending
something which may or may not have already caused a state transition).

"A server transaction MUST NOT discard transaction state based only on
 encountering a non-recoverable transport error when sending a
 response.  Instead, the associated INVITE server transaction state
 machine MUST remain in its current state.  (Timers will eventually
 cause it to transition to the "Terminated" state).  This allows
 retransmissions of the INVITE to be absorbed instead of being
 processed as a new request."
I think you've become confused about what the transition conditions
say. I think you're trying to read "send response" as "successfully sent
response". It just means that you passed  it to the transport layer,
which may come back and say it had trouble later.
(Search for "MUST be passed to the transport layer" in RFC3261.)

The thing you should point to is the second paragraph of 7.1:
"    If the SIP element's TU (Transaction User) issues a 2xx response for
   this transaction while the state machine is in the "Proceeding"
   state, the state machine MUST transition to the "Accepted" state and
   set Timer L to 64*T1, where T1 is the round-trip time estimate
   defined in Section 17.1.1.1 of [RFC3261]."

and the corresponding language for 3xx-6xx in RFC3261.




-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert
Sparks
Sent: Monday, June 23, 2014 7:05 PM
To: sipcore@ietf.org
Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck
within Proceeding

Just to make sure folks aren't misreading one thing - you would
only remain in the proceeding state while the TU has only handed you
1xx responses (or no response at all). Even if there were transport
errors, if the TU hands you a 2xx, you will transition to Accepted
(and possibly spin there for a bit if trying to send the 2xx causes
a transport error), or to Completed for 300 and greater responses.
Timers in the INVITE server state machine will drain you out of
Accepted
or Completed.

Nothing drains you from proceeding because Invite transactions
are designed to be able to pend forever. What will take you out of that
state is either the peer changing the state (such as with a CANCEL), or
the TU handing down a final response.

And the TU is the thing that needs to make the decision on the final
response. It's what knows enough to clean up application state if it
decides to give up on a long pending transaction.

RjS

On 6/23/14, 8:57 AM, Michael Procter wrote:

My recollection is that the only way for the IST to leave

"Proceeding"

is to receive a final response from the Transaction User.  Once a
final response is received, the remaining transitions to "Terminated"
are guarded by timers H, I, and L.

I'm not aware of a timer guarding the final response from the TU,
except for one requested in an Expires header.  I think it is

probably

reasonable to assume that the transaction layer and transaction user
are sufficiently closely coupled that they communicate reliably and

so

don't need a timer.  If an implementation can't make that assumption,
then I think timer C is probably morally acceptable since it guards a
similar condition for proxies.

Regards,

Michael

On 23 June 2014 11:55, Brett Tate <brett@broadsoft.com> wrote:

Hi,

A RFC 6026 thread on sip-implementors raises a question concerning

what

timer(s) were expected to be used to eventually allow the transition

from

Proceeding to Terminated when stuck in Proceeding because of the RFC

6026

requirement to remain in the current state during non-recoverable
transport error situations.  Within the following paragraph, was a
proprietary timer expected to be used while within Proceeding?  If

not,

what RFC defined timer was expected to be used?

"A server transaction MUST NOT discard transaction state based only

on

  encountering a non-recoverable transport error when sending a
  response.  Instead, the associated INVITE server transaction state
  machine MUST remain in its current state.  (Timers will eventually
  cause it to transition to the "Terminated" state).  This allows
  retransmissions of the INVITE to be absorbed instead of being
  processed as a new request."

Thanks,
Brett

_______________________________________________
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

--------------020106040500040508020400-- From nobody Wed Jun 25 10:00: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 8B51D1B2A4F for ; Wed, 25 Jun 2014 10:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 IF41e8IwwVWu for ; Wed, 25 Jun 2014 10:00:24 -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 C1A981B2A10 for ; Wed, 25 Jun 2014 10:00:21 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5PH0GnQ062917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 25 Jun 2014 12:00:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53AB0021.7020605@nostrum.com> Date: Wed, 25 Jun 2014 12:00:17 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <20140617212748.31334.32062.idtracker@ietfa.amsl.com>, <53A0B45E.3020909@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D399481@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D399481@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------060906000500070007080705" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9N3hBgxdEJOglPUTgdrFS4rfz1c Subject: Re: [sipcore] Fwd: New Version Notification for 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: Wed, 25 Jun 2014 17:00:35 -0000 This is a multi-part message in MIME format. --------------060906000500070007080705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Christer - sorry for the lag in the response here. On 6/20/14, 3:34 AM, Christer Holmberg wrote: > Hi, > I assume the semantics of the suggested new 'explicitsub' option > tag would be "MUST SUPPORT *AND* MUST USE". > (I.e. the option tag can be used to ensure that the receiver will not > create a subscription, instead of simply making sure the receiver > understands the meaning of, and supports the mechanism associated > with, the option-tag?) Yes, that's right. > Regards, > Christer > ------------------------------------------------------------------------ > *From:* sipcore [sipcore-bounces@ietf.org] on behalf of Robert Sparks > [rjsparks@nostrum.com] > *Sent:* Wednesday, 18 June 2014 12:34 AM > *To:* sipcore@ietf.org > *Subject:* [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-00.txt > > The other idea we started discussing in London: > > > -------- Original Message -------- > Subject: New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-00.txt > Date: Tue, 17 Jun 2014 14:27:48 -0700 > From: internet-drafts@ietf.org > To: Robert Sparks , "Robert Sparks" > > > > A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-00.txt > has been successfully submitted by Robert Sparks and posted to the > IETF repository. > > Name: draft-sparks-sipcore-refer-explicit-subscription > Revision: 00 > Title: Explicit Subscriptions for the REFER Method > Document date: 2014-06-17 > Group: Individual Submission > Pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-00.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-00 > > > 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 > > > --------------060906000500070007080705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Christer - sorry for the lag in the response here.

On 6/20/14, 3:34 AM, Christer Holmberg wrote:
Hi,
 
I assume the semantics of the suggested new 'explicitsub' option tag would be "MUST SUPPORT *AND* MUST USE".
 
(I.e. the option tag can be used to ensure that the receiver will not create a subscription, instead of simply making sure the receiver understands the meaning of, and supports the mechanism associated with, the option-tag?)
Yes, that's right.
 
Regards,
 
Christer
 
From: sipcore [sipcore-bounces@ietf.org] on behalf of Robert Sparks [rjsparks@nostrum.com]
Sent: Wednesday, 18 June 2014 12:34 AM
To: sipcore@ietf.org
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt

The other idea we started discussing in London:


-------- Original Message --------
Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt
Date: Tue, 17 Jun 2014 14:27:48 -0700
From: internet-drafts@ietf.org
To: Robert Sparks <rjs@nostrum.com>, "Robert Sparks" <RjS@nostrum.com> 


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

Name:		draft-sparks-sipcore-refer-explicit-subscription
Revision:	00
Title:		Explicit Subscriptions for the REFER Method
Document date:	2014-06-17
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-00.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-00


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



--------------060906000500070007080705-- From nobody Wed Jun 25 13:07: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 8F4641B2E58 for ; Wed, 25 Jun 2014 13:07:49 -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_50=0.8, 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 NnZjysLvoTXZ for ; Wed, 25 Jun 2014 13:07:45 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3751A04CD for ; Wed, 25 Jun 2014 13:07:45 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta07.westchester.pa.mail.comcast.net with comcast id JfnC1o0011swQuc57k7kD3; Wed, 25 Jun 2014 20:07:44 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta15.westchester.pa.mail.comcast.net with comcast id Jk7k1o00G1KKtkw3bk7kpG; Wed, 25 Jun 2014 20:07:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s5PK7iU1030784; Wed, 25 Jun 2014 16:07:44 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s5PK7hLB030783; Wed, 25 Jun 2014 16:07:43 -0400 Date: Wed, 25 Jun 2014 16:07:43 -0400 Message-Id: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403726864; bh=LkKnugRlsvR8hl6vka7DyLETijX97yeu+vyCZ4BpEHI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=HBAYccINC0TmR67smXsc5m4pQWu96DLbEY4CDYApXTytzlAuxdbcsxzZk5ehqs5fj YS9wG5tRvtg9XfwrrWvo3iZaDC3haDrCvpGfKAASj7n3gjh0ujrY6flZ63BGUK6LKr u7ReY3smv85yzwwRcwhnjnZzf/z3+ktfQ2FsKghz91A+1zdaLBAxzlo9yJUQvm0JIy 2wfe4Ljutfw2l3uHUU3SiN00jA3tpsO5G5xfSCNPu1tt6wvvOlB8tMfsqczyMK+Dw2 w+SmT8Kx64RL80uRlvieQ6ZmRBmRJhmAo4Fobju+P1zd5i+bMdvzrsyDAXI5LpndU7 Q7nx04ojO81Kw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/I0BDlDaPX9Fs6TNwrm3P3xn1IxI Cc: sipcore@ietf.org Subject: [sipcore] draft-yusef-sipcore-sip-oauth-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, 25 Jun 2014 20:07:50 -0000 Here are some thoughts on draft-yusef-sipcore-sip-oauth-00, mostly on section 3. I don't want to sound too critical here, but there are a bunch of details that could be cleared up in the -01. The subject is a bit slippery because it isn't really "OAuth used to authenticate SIP", but an OAuth-like protocol used to authenticate SIP. (I got wrong-footed before I realized that.) So the draft needs to spell out all the details of the operations, because you can't reliably interpolate what parts of OAuth are to be copied into the protocol. Similarly, the list of OAuth roles isn't particularly informative, because the roles in SIP have somewhat different functions and different names. (That wrong-footed me before I realized the OAuth roles weren't a guide to how the protocol worked.) It seems like we do not *need* to use 3xx responses to the first REGISTER request and the final GET request. (Though they might prove to be convenient for various reasons.) In OAuth, these are needed because the sequencing of these requests must be done by the browser, which is assumed to not understand the OAuth protocol flow; the 3xx responses direct it to perform the correct sequence. In the SIP case, we assume that the UA knows the OAuth sequence. So we could have the response to the first REGISTER be a 4xx response, and the response to the final GET be a 200 response, and the UA would still know what to do. It would be good to know how the first REGISTER response interoperates when there are other authentication mechanisms present. I'd expect a 407 response with suitable Proxy-Authenticate headers; the grammar allows a wide variety of authentication challenges, and the authorization server URL could be returned in one of them, while challenges for different auth. methods could be in others. It appears that the message flow requires the process to start with a REGISTER method, because the proxy needs to return the "token". Is this true? It would be better if the process could start with any request, because the UA might discover at any moment that it has stale authentication values. If there is a dependency of authentication on registration, this should be spelled out explicitly as a design feature/constraint. A design feature of OAuth is that the authorization server redirects the user's browser back to the location of the initial HTTP request after the user authenticates himself. This is accomplished by the server of the initial request providing a redirection to the authentication server that includes the original URL as a parameter. The details of this are fixed in the OAuth specification. Since we assume the UA knows the OAuth-SIP message sequence, we can have the UA remember the destination of the original request. On the other hand, if we want the authorization server to have control, that part of the message sequence needs to be specified (which isn't now). The correspondence of phrases like "the initial request" with the messages in the flow diagram is not very clear. E.g., in section 3.3, "the initial request" is the first GET, which is the 3rd message in the diagram, and the 2nd "request" in the diagram. It would help to name the messages (the convention seems to be F1, F2, etc.) and refer to the messages by name in the text. It would help if the semantics of some of the data items was explained. For instance, the response to the second GET includes a "code", but there is no description of what its semantics are -- is it secret? does it contain information about the requester's identity? is it signed by the auth. server? Similarly for "master-key" and "token". It's not clear to me why the 1st GET request needs a client-side nonce ("state"). The text says that it's to prevent replay attacks, but the transaction with the auth. server seems to be idempotent. Or is it assumed that the auth. server stores exactly one master-key for each user identity? (Perhaps this is knowledge that I would have if I understood OAuth.) In any case, how the auth. server checks for replays needs to be detailed. It's not clear to me why the UA is required to use the code to obtain a token. Isn't the possession of the code sufficient proof of identity of the requester? (This is also seen in OAuth, but I didn't spot the explanation of the need for the two-step process to obtain authorization for a request.) In section 3.6, it seems that "some-request-headers" is intended to be the same as "digest-string" in section 9 of RFC 4474. If so, it would make things clearer to call it "digest-string". It would help if the authentication processes that are carried out were specified explicitly. For instance, when the proxy receives an authenticated request, all the proxy has to go on is the "pop" value in the Authorization header, and since it's a hash, it doesn't explicitly contain the user's identity. Presumably the Proxy is supposed to obtain the identity from some other element in the request, use that identity to look up the recorded master-key, use that to compute what the "pop" should be, and verify that is correct. This implies that there is only one or a small number of master-keys that are valid for any particular user at one time, and that the proxy has a list of them. Indeed, as a design question, what information is the proxy required to know? In Basic and Digest authentication, it must know all the user names and passwords. But it's conceivable that this scheme delegates all user-level information to the auth. server, and all the proxy needs to know is how to verify that a token was issued by the auth. server. Since this is a major architectural feature, it would help if this was stated explicitly. And I notice that the "authenticated request" process does not depend on the "token" value. What is the token used for? Or is there a mistake here? Dale From nobody Sat Jun 28 03:26: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 CDB851A033B for ; Sat, 28 Jun 2014 03:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 al0WUsGLdaXc for ; Sat, 28 Jun 2014 03:26:46 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010: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 CDCCE1A0334 for ; Sat, 28 Jun 2014 03:26:45 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id gf5so3664562lab.36 for ; Sat, 28 Jun 2014 03:26:43 -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=b2ZPAsLNaOhmMcRLW1R9v0jQo8k97C4en/O5tuFZ/VI=; b=k24dNSBSelInHHgX+FKjzgF1MxgZKj86Qwxv7gRnO/Jim4ngSdbmYd05awvOi4C7pt dE+qHvyD0v8HgRs5biEKhKRntLRRE/x40OrEf3cJ+DXsnG3TkjgF8EKlXkg4PvmGPkxG e/hg6reKZMzlZGQQctWlyZDgtMTOlx8gubhdFrkjxw/LhEVO947a6nPolC+uKHiVhLKm XXtApq5MYkNghpQnBMI9te4ehoppyqhJdSctrXn34w+l5L69OC/QW+XDARkFJJrK9LrS c8S7+g4uOFenO+kk5tuVojU5IkEcZTuQCwkxymLUXyBen6DC5deSR5Rnc3b/2BUss/q7 IdMA== MIME-Version: 1.0 X-Received: by 10.152.22.169 with SMTP id e9mr1463062laf.51.1403951203816; Sat, 28 Jun 2014 03:26:43 -0700 (PDT) Received: by 10.114.13.100 with HTTP; Sat, 28 Jun 2014 03:26:43 -0700 (PDT) In-Reply-To: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> References: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> Date: Sat, 28 Jun 2014 06:26:43 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=089e0160bf8ac91bfd04fce2dcca Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/UCHFcUm5SfMNnvPpqdEtrOOZIAg Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-sip-oauth-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: Sat, 28 Jun 2014 10:26:50 -0000 --089e0160bf8ac91bfd04fce2dcca Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, Thanks for the detailed review. Please, see my reply inline... Regards, Rifaat On Wed, Jun 25, 2014 at 4:07 PM, Dale R. Worley wrote: > Here are some thoughts on draft-yusef-sipcore-sip-oauth-00, mostly on > section 3. I don't want to sound too critical here, but there are a > bunch of details that could be cleared up in the -01. > > I want you be be critical :), because I want to improve this document. I did mention in my email to the mailing list that the draft is still missing many details, I just wanted to get the discussion started. > The subject is a bit slippery because it isn't really "OAuth used to > authenticate SIP", but an OAuth-like protocol used to authenticate > SIP. (I got wrong-footed before I realized that.) So the draft needs > to spell out all the details of the operations, because you can't > reliably interpolate what parts of OAuth are to be copied into the > protocol. > > I think the document clearly states that it is trying to define a framework that is *based* on OAuth 2.0 framework. > Similarly, the list of OAuth roles isn't particularly informative, > because the roles in SIP have somewhat different functions and > different names. (That wrong-footed me before I realized the OAuth > roles weren't a guide to how the protocol worked.) > > I am planning on adding more details to this section. > It seems like we do not *need* to use 3xx responses to the first > REGISTER request and the final GET request. (Though they might prove > to be convenient for various reasons.) In OAuth, these are needed > because the sequencing of these requests must be done by the browser, > which is assumed to not understand the OAuth protocol flow; the 3xx > responses direct it to perform the correct sequence. In the SIP case, > we assume that the UA knows the OAuth sequence. So we could have the > response to the first REGISTER be a 4xx response, and the response to > the final GET be a 200 response, and the UA would still know what to > do. > > Paul has already raised this issue on the mailing list, and I agree that 401 would be a valid approach too. > It would be good to know how the first REGISTER response interoperates > when there are other authentication mechanisms present. I'd expect a > 407 response with suitable Proxy-Authenticate headers; the grammar > allows a wide variety of authentication challenges, and the > authorization server URL could be returned in one of them, while > challenges for different auth. methods could be in others. > > The challenge-response mechanism is well-defined and allows different schemes to be used. The current proposal uses the Digest scheme, but others could be used. But for the first REGISTER in the flow in section 3, the 401 should not include an authenticate header as the proxy is not challenging the request, only a way to redirect the UA to the authorization server. > It appears that the message flow requires the process to start with a > REGISTER method, because the proxy needs to return the "token". Is > this true? It would be better if the process could start with any > request, because the UA might discover at any moment that it has stale > authentication values. If there is a dependency of authentication on > registration, this should be spelled out explicitly as a design > feature/constraint. > > No, the REGISTER request could include a token (See section 5). I will make sure to clarify this in section 3. > A design feature of OAuth is that the authorization server redirects > the user's browser back to the location of the initial HTTP request > after the user authenticates himself. This is accomplished by the > server of the initial request providing a redirection to the > authentication server that includes the original URL as a parameter. > The details of this are fixed in the OAuth specification. Since we > assume the UA knows the OAuth-SIP message sequence, we can have the UA > remember the destination of the original request. On the other hand, > if we want the authorization server to have control, that part of the > message sequence needs to be specified (which isn't now). > > I do not think that the authorization server should have the control here. It should be the responsibility of the UA to use the correct outbound proxy. > The correspondence of phrases like "the initial request" with the > messages in the flow diagram is not very clear. E.g., in section 3.3, > "the initial request" is the first GET, which is the 3rd message in > the diagram, and the 2nd "request" in the diagram. It would help to > name the messages (the convention seems to be F1, F2, etc.) and refer > to the messages by name in the text. > > Ok > It would help if the semantics of some of the data items was > explained. For instance, the response to the second GET includes a > "code", but there is no description of what its semantics are -- is it > secret? does it contain information about the requester's identity? > is it signed by the auth. server? Similarly for "master-key" and > "token". > > Ok > It's not clear to me why the 1st GET request needs a client-side nonce > ("state"). The text says that it's to prevent replay attacks, but the > transaction with the auth. server seems to be idempotent. Or is it > assumed that the auth. server stores exactly one master-key for each > user identity? (Perhaps this is knowledge that I would have if I > understood OAuth.) In any case, how the auth. server checks for > replays needs to be detailed. > > Good point. The 1st GET does not need to include that; only the 2nd GET. > It's not clear to me why the UA is required to use the code to obtain > a token. Isn't the possession of the code sufficient proof of > identity of the requester? (This is also seen in OAuth, but I didn't > spot the explanation of the need for the two-step process to obtain > authorization for a request.) > > This is explained in RFC6749, section 1.3.1. > In section 3.6, it seems that "some-request-headers" is intended to be > the same as "digest-string" in section 9 of RFC 4474. If so, it would > make things clearer to call it "digest-string". > > Ok. > It would help if the authentication processes that are carried out > were specified explicitly. For instance, when the proxy receives an > authenticated request, all the proxy has to go on is the "pop" value > in the Authorization header, and since it's a hash, it doesn't > explicitly contain the user's identity. Presumably the Proxy is > supposed to obtain the identity from some other element in the > request, use that identity to look up the recorded master-key, use > that to compute what the "pop" should be, and verify that is correct. > > OK > This implies that there is only one or a small number of master-keys > that are valid for any particular user at one time, and that the proxy > has a list of them. > > Indeed, as a design question, what information is the proxy required > to know? In Basic and Digest authentication, it must know all the > user names and passwords. But it's conceivable that this scheme > delegates all user-level information to the auth. server, and all the > proxy needs to know is how to verify that a token was issued by the > auth. server. Since this is a major architectural feature, it would > help if this was stated explicitly. > > Ok > And I notice that the "authenticated request" process does not depend > on the "token" value. What is the token used for? Or is there a > mistake here? > > The token is used to control the various services and the level of service allowed for the user in possession of the token. > Dale > --089e0160bf8ac91bfd04fce2dcca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dale,

Thanks for the detailed review= .
Please, see my reply inline...

Regards= ,
=A0Rifaat


On Wed, Jun 25, 2014 at 4:07 PM, Dale R. Worley <worley@ariadne.com&g= t; wrote:
Here are some thoughts on draft-yusef-sipcore-sip-oauth-00, mostly on
section 3. =A0I don't want to sound too critical here, but there are a<= br> bunch of details that could be cleared up in the -01.


I want you be be critical :), because = I want to improve this document.
I did mention in my email to the= mailing list that the draft is still missing many details, I just wanted t= o get the discussion started.

=A0
The subject is a bit slippery because it isn't really "OAuth used = to
authenticate SIP", but an OAuth-like protocol used to authenticate
SIP. =A0(I got wrong-footed before I realized that.) =A0So the draft needs<= br> to spell out all the details of the operations, because you can't
reliably interpolate what parts of OAuth are to be copied into the
protocol.


I think the document clearly states th= at it is trying to define a framework that is *based* on OAuth 2.0 framewor= k.

=A0
Similarly, the list of OAuth roles isn't particularly informative,
because the roles in SIP have somewhat different functions and
different names. =A0(That wrong-footed me before I realized the OAuth
roles weren't a guide to how the protocol worked.)


I am planning on adding more details t= o this section.

=A0
It seems like we do not *need* to use 3xx responses to the first
REGISTER request and the final GET request. =A0(Though they might prove
to be convenient for various reasons.) =A0In OAuth, these are needed
because the sequencing of these requests must be done by the browser,
which is assumed to not understand the OAuth protocol flow; the 3xx
responses direct it to perform the correct sequence. =A0In the SIP case, we assume that the UA knows the OAuth sequence. =A0So we could have the
response to the first REGISTER be a 4xx response, and the response to
the final GET be a 200 response, and the UA would still know what to
do.


Paul has already raised this issue on = the mailing list, and I agree that 401 would be a valid approach too.
=

=A0
It would be good to know how the first REGISTER response interoperates
when there are other authentication mechanisms present. =A0I'd expect a=
407 response with suitable Proxy-Authenticate headers; the grammar
allows a wide variety of authentication challenges, and the
authorization server URL could be returned in one of them, while
challenges for different auth. methods could be in others.


The challenge-response mechanism is we= ll-defined and allows different schemes to be used.
The current p= roposal uses the Digest scheme, but others could be used.

But for the first REGISTER in the flow in section 3, the 401 sho= uld not include an authenticate header as the proxy is not challenging the = request, only a way to redirect the UA to the authorization server.

=A0
It appears that the message flow requires the process to start with a
REGISTER method, because the proxy needs to return the "token". = =A0Is
this true? =A0It would be better if the process could start with any
request, because the UA might discover at any moment that it has stale
authentication values. =A0If there is a dependency of authentication on
registration, this should be spelled out explicitly as a design
feature/constraint.


No, the REGISTER request could include= a token (See section 5). I will make sure to clarify this in section 3.

=A0
A design feature of OAuth is that the authorization server redirects
the user's browser back to the location of the initial HTTP request
after the user authenticates himself. =A0This is accomplished by the
server of the initial request providing a redirection to the
authentication server that includes the original URL as a parameter.
The details of this are fixed in the OAuth specification. =A0Since we
assume the UA knows the OAuth-SIP message sequence, we can have the UA
remember the destination of the original request. =A0On the other hand,
if we want the authorization server to have control, that part of the
message sequence needs to be specified (which isn't now).


I do not think that the authorization = server should have the control here. It should be the responsibility of the= UA to use the correct outbound proxy.

=A0
The correspondence of phrases like "the initial request" with the=
messages in the flow diagram is not very clear. =A0E.g., in section 3.3, "the initial request" is the first GET, which is the 3rd message = in
the diagram, and the 2nd "request" in the diagram. =A0It would he= lp to
name the messages (the convention seems to be F1, F2, etc.) and refer
to the messages by name in the text.


Ok

=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"> It would help if the semantics of some of the data items was
explained. =A0For instance, the response to the second GET includes a
"code", but there is no description of what its semantics are -- = is it
secret? =A0does it contain information about the requester's identity?<= br> is it signed by the auth. server? =A0Similarly for "master-key" a= nd
"token".


Ok

=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"> It's not clear to me why the 1st GET request needs a client-side nonce<= br> ("state"). =A0The text says that it's to prevent replay attac= ks, but the
transaction with the auth. server seems to be idempotent. =A0Or is it
assumed that the auth. server stores exactly one master-key for each
user identity? =A0(Perhaps this is knowledge that I would have if I
understood OAuth.) =A0In any case, how the auth. server checks for
replays needs to be detailed.


Good point. The 1st GET does not need = to include that; only the 2nd GET.

=A0
It's not clear to me why the UA is required to use the code to obtain a token. =A0Isn't the possession of the code sufficient proof of
identity of the requester? =A0(This is also seen in OAuth, but I didn't=
spot the explanation of the need for the two-step process to obtain
authorization for a request.)


This is explained in RFC6749, section = 1.3.1.

=A0
In section 3.6, it seems that "some-request-headers" is intended = to be
the same as "digest-string" in section 9 of RFC 4474. =A0If so, i= t would
make things clearer to call it "digest-string".


Ok.

=A0
=
It would help if the authentication processes that are carried out
were specified explicitly. =A0For instance, when the proxy receives an
authenticated request, all the proxy has to go on is the "pop" va= lue
in the Authorization header, and since it's a hash, it doesn't
explicitly contain the user's identity. =A0Presumably the Proxy is
supposed to obtain the identity from some other element in the
request, use that identity to look up the recorded master-key, use
that to compute what the "pop" should be, and verify that is corr= ect.


OK

=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"> This implies that there is only one or a small number of master-keys
that are valid for any particular user at one time, and that the proxy
has a list of them.

Indeed, as a design question, what information is the proxy required
to know? =A0In Basic and Digest authentication, it must know all the
user names and passwords. =A0But it's conceivable that this scheme
delegates all user-level information to the auth. server, and all the
proxy needs to know is how to verify that a token was issued by the
auth. server. =A0Since this is a major architectural feature, it would
help if this was stated explicitly.


Ok

=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"> And I notice that the "authenticated request" process does not de= pend
on the "token" value. =A0What is the token used for? =A0Or is the= re a
mistake here?


The token is used to control the various services and the level of se= rvice allowed for the user in possession of the token.

=A0
Dale

--089e0160bf8ac91bfd04fce2dcca-- From nobody Mon Jun 30 03:50: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 DDA861A01FA for ; Mon, 30 Jun 2014 03:50:31 -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 gKKQa6KZarw2 for ; Mon, 30 Jun 2014 03:50:30 -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 B2EF31A01F9 for ; Mon, 30 Jun 2014 03:50:29 -0700 (PDT) X-AuditID: c1b4fb30-f79da6d000006b80-72-53b140f38ece Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.E4.27520.3F041B35; Mon, 30 Jun 2014 12:50:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 12:50:27 +0200 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt Thread-Index: AQHPinPsKXARpYQS/Ue+yBtdwbAQ1Zt5r4XYgAhH7ICAB5O/jQ== Date: Mon, 30 Jun 2014 10:50:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3AB292@ESESSMB209.ericsson.se> References: <20140617212748.31334.32062.idtracker@ietfa.amsl.com>, <53A0B45E.3020909@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D399481@ESESSMB209.ericsson.se>, <53AB0021.7020605@nostrum.com> In-Reply-To: <53AB0021.7020605@nostrum.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje5nh43BBu/Pq1lcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvj24RXjAUrRCp+/u9lbmCcIdDFyMkhIWAi 8WfTASYIW0ziwr31bF2MXBxCAkcZJU6v3QDlLGKUODBvMUsXIwcHm4CFRPc/bZAGEYFAiYWT lrCA2MICRRId++azQMSLJS6vv8gMYTtJPDy6jxWklUVAVeLdezmQMK+Ar8TtHRPYIcYfZpQ4 dWkWO0iCU0BbYtryi2BzGIEO+n5qDdhxzALiEreezIc6VEBiyZ7zzBC2qMTLx/9YIWxFifan DYwQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWpyU m25kpJdalJlcXJyfp5eXWrKJERgnB7f8NtjB+PK54yFGAQ5GJR7eh382BAuxJpYVV+YeYpTm YFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbJW055BfXO1V28slg24ZGA0Gpb hvY9FQ+f27XYbq/y3yLxzTz2+eb7+X0hWicUddRnN9rKeCcI6UQ/lj75x8X024nJ101tXRzq eh7+yDh24MvFv+VbleX/MTZVG2xQUtp8yXYFz43s7QdWcRgm/Lv3Xtv1S3K9YXfZAk+/WaVP J9unbJZ3LlFiKc5INNRiLipOBAAp3EqndAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/6WfXlx8ZG4cd05JdJ-d8j5lUb-A Subject: Re: [sipcore] Fwd: New Version Notification for 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, 30 Jun 2014 10:50:32 -0000 Hi, >>I assume the semantics of the suggested new 'explicitsub' option tag woul= d be "MUST SUPPORT *AND* MUST USE".=20 >> >>(I.e. the option tag can be used to ensure that the receiver will not cre= ate a subscription, instead of simply making sure the receiver understands = the meaning of, and supports the mechanism associated with, the option-tag?= ) > >Yes, that's right. Thanks for the clarification! I think we need to make that very clear in th= e draft, to avoid confusion in the future :) So, I think this extension would be useful. Regards, Christer From: sipcore [sipcore-bounces@ietf.org] on behalf of Robert Sparks [rjspar= ks@nostrum.com] Sent: Wednesday, 18 June 2014 12:34 AM To: sipcore@ietf.org Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-r= efer-explicit-subscription-00.txt The other idea we started discussing in London: -------- Original Message -------- Subject: New Version Notification for dr= aft-sparks-sipcore-refer-explicit-subscription-00.txt Date: Tue, 17 Jun 2014 14:27:48 -0700 From: internet-drafts@ietf.org To: Robert Sparks , "Robert Sparks" A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-00.t= xt has been successfully submitted by Robert Sparks and posted to the IETF repository. Name: draft-sparks-sipcore-refer-explicit-subscription Revision: 00 Title: Explicit Subscriptions for the REFER Method Document date: 2014-06-17 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-sparks-sipcore-re= fer-explicit-subscription-00.txt Status: https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer= -explicit-subscription/ Htmlized: http://tools.ietf.org/html/draft-sparks-sipcore-refer-expli= cit-subscription-00 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. = =20 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= From nobody Mon Jun 30 07:58: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 6AA4E1A0367 for ; Mon, 30 Jun 2014 07:58:33 -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 fRfFLcNF8cdS for ; Mon, 30 Jun 2014 07:58:32 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD081A035C for ; Mon, 30 Jun 2014 07:58:32 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id LcMo1o0031c6gX85BeyX01; Mon, 30 Jun 2014 14:58:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id LeyX1o0163ZTu2S3jeyXje; Mon, 30 Jun 2014 14:58:31 +0000 Message-ID: <53B17B17.7000100@alum.mit.edu> Date: Mon, 30 Jun 2014 10:58: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: sipcore@ietf.org References: <20140617212748.31334.32062.idtracker@ietfa.amsl.com> <53A0B45E.3020909@nostrum.com> In-Reply-To: <53A0B45E.3020909@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=1404140311; bh=8nEujzcsWMF/rp5V57O4EfaG4qOu7TKZVVWxTgB/bn0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lJa+HtjE8mzdWUX9yDt87eevcXdblqLl9yqEO0CmtCVL5kbygc2TZAj56G7PWRJ4D wQfDsb8LnKlPx4GCE0KPlZ0IzAl6/UjtwE2B3Oww2kCYMJqmsJQ3od8EtHC4VlwDKd +oV8MoEWkPvs4m2XcMNF15pbKCYtDGducAIqYSp8RoXB7v08Qpipwoj+5KRSk7ajho VX88IslQPfg8arpHGxXhtUXEHYdinEsuazHWrzuyn0SaCkBxmWcJONw0GO7PclhbYT hV2rlBY5rtFpGQqwiFFeYNeGp5Ou/fUy7fOBCLQSbN8munU4WI+ABh8RbJjpwo3Jxf ONpxQnLm4qT9g== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/7zWS_BFePYeZRVvwqWwMG8SC8is Subject: Re: [sipcore] Fwd: New Version Notification for 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, 30 Jun 2014 14:58:33 -0000 Robert, Thanks for doing this. I think it suggests an approach that could meet most or all of the concerns that people have with the current mechanisms. Regarding 5.4 (Could this deprecate RFC4488): This section discusses what a server can do if it doesn't wish to provide a subscription. But 4488 is about what a client should do if it doesn't want a subscription. This new draft satisfies the client needs *without* section 5.4. The mechanism you mention in 5.4 satisfies a new need. Now consider one more thing: suppose the client wants to do the refer in dialog, and has no intention of establishing a subscription. So he doesn't care what the returned Refer-Events-At URI is. Potentially this costs the server some resources, to be prepared to receive the subscription request that will never be coming. If the client had a way to say that no subscription will be coming, then that would allow the server to avoid the cost. So it would be helpful to have a mechanism to indicate that it doesn't want an implicit subscription and also doesn't need any way to establish an explicit subscription. The new mechanisms from this draft could be combined with those from 4488 to accomplish this. E.g., Require: explicitsub Refer-Sub: false Alternatively we could define a new way to signal this. Otherwise this draft seems good. Thanks, Paul On 6/17/14 5:34 PM, Robert Sparks wrote: > The other idea we started discussing in London: > > > -------- Original Message -------- > Subject: New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-00.txt > Date: Tue, 17 Jun 2014 14:27:48 -0700 > From: internet-drafts@ietf.org > To: Robert Sparks , "Robert Sparks" > > > > A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-00.txt > has been successfully submitted by Robert Sparks and posted to the > IETF repository. > > Name: draft-sparks-sipcore-refer-explicit-subscription > Revision: 00 > Title: Explicit Subscriptions for the REFER Method > Document date: 2014-06-17 > Group: Individual Submission > Pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-00.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-00 > > > 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 > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Jun 30 09:27: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 08A6A1A03AE for ; Mon, 30 Jun 2014 09:27: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 j4D4wipeA2DH for ; Mon, 30 Jun 2014 09:27:22 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 26A741A03B8 for ; Mon, 30 Jun 2014 09:27:20 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id Lg1o1o00227AodY53gTKlv; Mon, 30 Jun 2014 16:27:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id LgTK1o00N3ZTu2S3fgTKbt; Mon, 30 Jun 2014 16:27:19 +0000 Message-ID: <53B18FE7.4090508@alum.mit.edu> Date: Mon, 30 Jun 2014 12:27: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: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> 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=1404145639; bh=rlBGWsrB07IxudLKBiTUDebnb/8/E36qK1caKQ/yZ7g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sN68ThdUu5l/D7jL4ia92iZ+IZ7fDzjlGpJcrhuLgfvAmayQgRbt7vyPoky+NAmhX 4g+oETybYcuEqDkcFShleWMYB/uMceazgTJsOi33Z0VEQB04XnbppqdqPB4qoNNTUE bMn75+qP4XW4fsmkl0q6l1XK/NQortsoljHwoGvUMQxi9naZIBG+kpbQMwwR+Q4CxX v/LuWb0M9G+ijRvjUxt5ShYffWahH2JUVGG6GndNbJq4YvZVQ0ZR8j5k7tFN7fohBK TdOYG/eyvGxZCwsjsZ6InGl/OnqaMNvT7QTCz5bP2It+gf8dC/wPLtHKiErPao7kOX oxhv/P8zW2Cfw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/b2zhhvtBMRvFp96GlKp5ZPPCweY Subject: Re: [sipcore] draft-yusef-sipcore-sip-oauth-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, 30 Jun 2014 16:27:23 -0000 On 6/28/14 6:26 AM, Rifaat Shekh-Yusef wrote: > It would be good to know how the first REGISTER response interoperates > when there are other authentication mechanisms present. I'd expect a > 407 response with suitable Proxy-Authenticate headers; the grammar > allows a wide variety of authentication challenges, and the > authorization server URL could be returned in one of them, while > challenges for different auth. methods could be in others. > > The challenge-response mechanism is well-defined and allows different > schemes to be used. > The current proposal uses the Digest scheme, but others could be used. > > But for the first REGISTER in the flow in section 3, the 401 should not > include an authenticate header as the proxy is not challenging the > request, only a way to redirect the UA to the authorization server. Isn't the proxy saying: I refuse your request because I require a correct "code"? That seems like a challenge to me. It just happens to also include hints on where to go to get a code. Thanks, Paul From nobody Mon Jun 30 09:59:48 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 951C11A03A5 for ; Mon, 30 Jun 2014 09:59: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 AAlcUmpLQpW5 for ; Mon, 30 Jun 2014 09:59:44 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BAE1A0397 for ; Mon, 30 Jun 2014 09:59:44 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id n15so5994838lbi.20 for ; Mon, 30 Jun 2014 09:59:42 -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=+SXtyk52naQMofrMKKbF9TV0p8YaNYx1PCOv3B/Ca/g=; b=o8+sgo6/tpzzXx3l8QtEn3cqmXGYxxOVCvqJccFJf4e7CfXX46JelVijPM/bvIs+bs EJ5QnjZR85IbptY2G7ulwkelfPUC8fnTZniUOSTKKhPnr03tnnUbjmQBnBmARXIPYVVo xYoZDbFTmOK+qtQw6gXpNBQcZlnNwSgU13Y0xu22tX9mYBms+8k047WZT8ikOLtOlPlN DZlDonJ+Fhshpncw3cz5Fim+Rf9nIsyjflu9uYU5/OFBJA0ozP8AnnlheBNYc83KWncx 63mdbIMTtaWUHlXlVPuHXQSj8u4rR0D6nxxdsxbzlbQuF/7F4n5LnEghZGwC2IqmV6yD 1/BQ== MIME-Version: 1.0 X-Received: by 10.112.198.33 with SMTP id iz1mr7412235lbc.49.1404147582525; Mon, 30 Jun 2014 09:59:42 -0700 (PDT) Received: by 10.114.13.100 with HTTP; Mon, 30 Jun 2014 09:59:42 -0700 (PDT) In-Reply-To: <53B18FE7.4090508@alum.mit.edu> References: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> <53B18FE7.4090508@alum.mit.edu> Date: Mon, 30 Jun 2014 12:59:42 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c341b4de67ff04fd1095c2 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/j4JsQjaSHM2Um8nXEcqSaiF7Z54 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-sip-oauth-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, 30 Jun 2014 16:59:46 -0000 --001a11c341b4de67ff04fd1095c2 Content-Type: text/plain; charset=ISO-8859-1 May be it is my wording that is a bit confusing here. The server includes the Authenticate header in the challenge to indicate to the client which scheme it must use to provide user's credentials in the response. In this case the server is not expecting the client to provide it with the user's credentials; instead it is expecting the client to provide the user's credentials to the authorization server. So, yes, in this case the proxy is challenging the client, but I do not see the need to include the Authenticate header in the challenge. Regards, Rifaat On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat wrote: > On 6/28/14 6:26 AM, Rifaat Shekh-Yusef wrote: > > It would be good to know how the first REGISTER response interoperates >> when there are other authentication mechanisms present. I'd expect a >> 407 response with suitable Proxy-Authenticate headers; the grammar >> allows a wide variety of authentication challenges, and the >> authorization server URL could be returned in one of them, while >> challenges for different auth. methods could be in others. >> >> The challenge-response mechanism is well-defined and allows different >> schemes to be used. >> The current proposal uses the Digest scheme, but others could be used. >> >> But for the first REGISTER in the flow in section 3, the 401 should not >> include an authenticate header as the proxy is not challenging the >> request, only a way to redirect the UA to the authorization server. >> > > Isn't the proxy saying: I refuse your request because I require a correct > "code"? That seems like a challenge to me. > > It just happens to also include hints on where to go to get a code. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c341b4de67ff04fd1095c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
May be it is my wording that is a bit confusing here.=

The server includes the Authenticate header in the cha= llenge to indicate to the client which scheme it must use to provide user&#= 39;s credentials in the response.
In this case the server is not expecting the client to provide it with the = user's credentials; instead it is expecting the client to provide the u= ser's credentials to the authorization server.

So, yes, in this case the proxy is challenging the client, but I do no= t see the need to include the Authenticate header in the challenge.

Regards,
=A0Rifaat



On Mon, Jun 3= 0, 2014 at 12:27 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 6/28/14 6:26 AM, Rifaat S= hekh-Yusef wrote:

=A0 =A0 It would be good to know how the first REGISTER response interopera= tes
=A0 =A0 when there are other authentication mechanisms present. =A0I'd = expect a
=A0 =A0 407 response with suitable Proxy-Authenticate headers; the grammar<= br> =A0 =A0 allows a wide variety of authentication challenges, and the
=A0 =A0 authorization server URL could be returned in one of them, while =A0 =A0 challenges for different auth. methods could be in others.

The challenge-response mechanism is well-defined and allows different
schemes to be used.
The current proposal uses the Digest scheme, but others could be used.

But for the first REGISTER in the flow in section 3, the 401 should not
include an authenticate header as the proxy is not challenging the
request, only a way to redirect the UA to the authorization server.

Isn't the proxy saying: I refuse your request because I require a corre= ct "code"? That seems like a challenge to me.

It just happens to also include hints on where to go to get a code.

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

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

--001a11c341b4de67ff04fd1095c2-- From nobody Mon Jun 30 10:12:33 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 0C4141A00A7 for ; Mon, 30 Jun 2014 10:12:28 -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 ynHS7NyyAkuG for ; Mon, 30 Jun 2014 10:12:27 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 006ED1A011B for ; Mon, 30 Jun 2014 10:12:26 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id Lh0t1o00616LCl058hCSMG; Mon, 30 Jun 2014 17:12:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id LhCS1o00b3ZTu2S3ShCSWt; Mon, 30 Jun 2014 17:12:26 +0000 Message-ID: <53B19A7A.8040408@alum.mit.edu> Date: Mon, 30 Jun 2014 13:12:26 -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: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> <53B18FE7.4090508@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=1404148346; bh=0DKTqCp0UmzL3sSavR4IdDY9yVvE9fYUGWj8ZWQo/io=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nfjXCnuFKort4Ai4erDYjVqXS+ooI8oK+aftpyc2Tcwo4eI+89sltB9J3GlMEi4AN IIHPG7Z/evuUqzPq91BFIIdxvKiry/haHtPvvgoLuWjBO0qXaQvrQBM+veIjdH979r Aud2ZkKFu9tU57HnBhCFqmY1woDW7wqQyAyo+j0tcOrnpbbt80gzbOJhxiGvfMm9BK Z4uqKBFySkQsdSk4RZVobIs31s1yKyt5Ucxyj5aET3T08WEc8ZeUWa0i2cARhLNOmT H1KjFdgCtOH7pSQk7ighgeCaOOtbUZ5rmfqfZL38xtTjbpM2JVcEQTBfC/jbOyNhC3 qTfUFao9NO6Ew== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/tzQGlh23tHjBjcxi4t7T99S8IRU Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-sip-oauth-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, 30 Jun 2014 17:12:28 -0000 On 6/30/14 12:59 PM, Rifaat Shekh-Yusef wrote: > May be it is my wording that is a bit confusing here. > > The server includes the Authenticate header in the challenge to indicate > to the client which scheme it must use to provide user's credentials in > the response. > In this case the server is not expecting the client to provide it with > the user's credentials; instead it is expecting the client to provide > the user's credentials to the authorization server. ISTM there are two different credentials: - an auth code presented by the client to the proxy - credentials presented to the auth server in order to get an auth code > So, yes, in this case the proxy is challenging the client, but I do not > see the need to include the Authenticate header in the challenge. There needs to be some way for the client to deliver the code to the server. The Authorization header, with a new scheme, would be a plausible way to do that. The challenge then says that credentials (the token) using the new scheme are required. Thanks, Paul > Regards, > Rifaat > > > > On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat > wrote: > > On 6/28/14 6:26 AM, Rifaat Shekh-Yusef wrote: > > It would be good to know how the first REGISTER response > interoperates > when there are other authentication mechanisms present. > I'd expect a > 407 response with suitable Proxy-Authenticate headers; the > grammar > allows a wide variety of authentication challenges, and the > authorization server URL could be returned in one of them, > while > challenges for different auth. methods could be in others. > > The challenge-response mechanism is well-defined and allows > different > schemes to be used. > The current proposal uses the Digest scheme, but others could be > used. > > But for the first REGISTER in the flow in section 3, the 401 > should not > include an authenticate header as the proxy is not challenging the > request, only a way to redirect the UA to the authorization server. > > > Isn't the proxy saying: I refuse your request because I require a > correct "code"? That seems like a challenge to me. > > It just happens to also include hints on where to go to get a code. > > Thanks, > Paul > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > From nobody Mon Jun 30 10:39:41 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 406C31A03B6 for ; Mon, 30 Jun 2014 10:39:39 -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 FoGqc2khAOfv for ; Mon, 30 Jun 2014 10:39:37 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1181A03B5 for ; Mon, 30 Jun 2014 10:39:35 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so6199840lbv.28 for ; Mon, 30 Jun 2014 10:39:34 -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=QvxF1E9+LjGZL9WrH3wjNcZwZ/Myjg1c4sk/37fxODA=; b=vvGJ7N0RyXiiWWzJuvyP5JbHJMKyX9QKnXYXtcyN5JOUYkcFBnPsrrCgc/my6wwyXu M2Nf09mnfzCEGAxvZfnsbQBw7JUo2A2VwgzkQRjSETkk4A7G4bSjX04iRNbL8WVpHGur CM+/DYp5QfDxPG/BIoPseR4KJcxqVbULJLsYHxwSMIFKu+1zyG/dB5K7TTQJCzM4k5NY A1BaznapsYdEFsPHmK+QLH+efXlaf/FlEONBcFcnshCAESj1GdDjsXlnfktVbqfh3BXx svGbtA6ompvNj51bpMWTlwN1GcGydpuWXrnggfKOir30IFMoTd7Lf3MvjpuET0zZyNl6 1rpg== MIME-Version: 1.0 X-Received: by 10.152.23.136 with SMTP id m8mr31826159laf.2.1404149974360; Mon, 30 Jun 2014 10:39:34 -0700 (PDT) Received: by 10.114.13.100 with HTTP; Mon, 30 Jun 2014 10:39:34 -0700 (PDT) In-Reply-To: <53B19A7A.8040408@alum.mit.edu> References: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> <53B18FE7.4090508@alum.mit.edu> <53B19A7A.8040408@alum.mit.edu> Date: Mon, 30 Jun 2014 13:39:34 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0158bf886ee6be04fd11249f Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/I44i7QgPjqz_0VZjV7x9Ij_DYV0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-sip-oauth-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, 30 Jun 2014 17:39:39 -0000 --089e0158bf886ee6be04fd11249f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 30, 2014 at 1:12 PM, Paul Kyzivat wrote: > On 6/30/14 12:59 PM, Rifaat Shekh-Yusef wrote: > >> May be it is my wording that is a bit confusing here. >> >> The server includes the Authenticate header in the challenge to indicate >> to the client which scheme it must use to provide user's credentials in >> the response. >> In this case the server is not expecting the client to provide it with >> the user's credentials; instead it is expecting the client to provide >> the user's credentials to the authorization server. >> > > ISTM there are two different credentials: > > - an auth code presented by the client to the proxy > - credentials presented to the auth server in order to get an auth code > > > So, yes, in this case the proxy is challenging the client, but I do not >> see the need to include the Authenticate header in the challenge. >> > > There needs to be some way for the client to deliver the code to the > server. The Authorization header, with a new scheme, would be a plausible > way to do that. Yes, and that is already described in the draft. > The challenge then says that credentials (the token) using the new scheme > are required. > > What is the benefit of the proxy explicitly stating that in the challenge? > Thanks, > Paul > > Regards, >> Rifaat >> >> >> >> On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat > > wrote: >> >> On 6/28/14 6:26 AM, Rifaat Shekh-Yusef wrote: >> >> It would be good to know how the first REGISTER response >> interoperates >> when there are other authentication mechanisms present. >> I'd expect a >> 407 response with suitable Proxy-Authenticate headers; the >> grammar >> allows a wide variety of authentication challenges, and the >> authorization server URL could be returned in one of them, >> while >> challenges for different auth. methods could be in others. >> >> The challenge-response mechanism is well-defined and allows >> different >> schemes to be used. >> The current proposal uses the Digest scheme, but others could be >> used. >> >> But for the first REGISTER in the flow in section 3, the 401 >> should not >> include an authenticate header as the proxy is not challenging the >> request, only a way to redirect the UA to the authorization >> server. >> >> >> Isn't the proxy saying: I refuse your request because I require a >> correct "code"? That seems like a challenge to me. >> >> It just happens to also include hints on where to go to get a code. >> >> Thanks, >> Paul >> >> _________________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/__listinfo/sipcore >> >> >> >> > --089e0158bf886ee6be04fd11249f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 30, 2014 at 1:12 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
On 6/30/14 12:59 PM, Rifaat = Shekh-Yusef wrote:
May be it is my wording that is a bit confusing here.

The server includes the Authenticate header in the challenge to indicate to the client which scheme it must use to provide user's credentials in=
the response.
In this case the server is not expecting the client to provide it with
the user's credentials; instead it is expecting the client to provide the user's credentials to the authorization server.

ISTM there are two different credentials:

- an auth code presented by the client to the proxy
- credentials presented to the auth server in order to get an auth code

So, yes, in this case the proxy is challenging the client, but I do not
see the need to include the Authenticate header in the challenge.

There needs to be some way for the client to deliver the code to the server= . The Authorization header, with a new scheme, would be a plausible way to = do that.

Yes, and that is already described= in the draft.
=A0
=A0
The challenge then says that credentials (the token) using the new scheme a= re required.

What is the benefit of the proxy explicitly stating t= hat in the challenge?

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

Regards,
=A0 Rifaat



On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
=
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 On 6/28/14 6:26 AM, Rifaat Shekh-Yusef wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0It would be good to know how the first REGISTER = response
=A0 =A0 =A0 =A0 interoperates
=A0 =A0 =A0 =A0 =A0 =A0 =A0when there are other authentication mechanisms p= resent.
=A0 =A0 =A0 =A0 =A0 I'd expect a
=A0 =A0 =A0 =A0 =A0 =A0 =A0407 response with suitable Proxy-Authenticate he= aders; the
=A0 =A0 =A0 =A0 grammar
=A0 =A0 =A0 =A0 =A0 =A0 =A0allows a wide variety of authentication challeng= es, and the
=A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server URL could be returned in on= e of them,
=A0 =A0 =A0 =A0 while
=A0 =A0 =A0 =A0 =A0 =A0 =A0challenges for different auth. methods could be = in others.

=A0 =A0 =A0 =A0 The challenge-response mechanism is well-defined and allows=
=A0 =A0 =A0 =A0 different
=A0 =A0 =A0 =A0 schemes to be used.
=A0 =A0 =A0 =A0 The current proposal uses the Digest scheme, but others cou= ld be
=A0 =A0 =A0 =A0 used.

=A0 =A0 =A0 =A0 But for the first REGISTER in the flow in section 3, the 40= 1
=A0 =A0 =A0 =A0 should not
=A0 =A0 =A0 =A0 include an authenticate header as the proxy is not challeng= ing the
=A0 =A0 =A0 =A0 request, only a way to redirect the UA to the authorization= server.


=A0 =A0 Isn't the proxy saying: I refuse your request because I require= a
=A0 =A0 correct "code"? That seems like a challenge to me.

=A0 =A0 It just happens to also include hints on where to go to get a code.=

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul

=A0 =A0 _________________________________________________
=A0 =A0 sipcore mailing list
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/sipcore
=A0 =A0 <https://www.ietf.org/mailman/listinfo/sipcore>



--089e0158bf886ee6be04fd11249f-- From nobody Mon Jun 30 11:25: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 83AE41A03FF for ; Mon, 30 Jun 2014 11:25:55 -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 mHr83f7cFnnl for ; Mon, 30 Jun 2014 11:25:54 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 6341E1A03F4 for ; Mon, 30 Jun 2014 11:25:54 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta08.westchester.pa.mail.comcast.net with comcast id LhZJ1o0040EZKEL58iRtE0; Mon, 30 Jun 2014 18:25:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id LiRt1o00h3ZTu2S3MiRtpl; Mon, 30 Jun 2014 18:25:53 +0000 Message-ID: <53B1ABB1.1010907@alum.mit.edu> Date: Mon, 30 Jun 2014 14:25:53 -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: <201406252007.s5PK7hLB030783@hobgoblin.ariadne.com> <53B18FE7.4090508@alum.mit.edu> <53B19A7A.8040408@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=1404152753; bh=cFkGt+L0i2n0nw4i+2+sARl/9cNCybiWbJZbVrHIOlM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m+JLMXEuRYt+a34Xm66suusMUn6mKKtW0y15ms9nGxZda3CIF2ShgrdyFCy9A20L8 /MVd0r4LGWKHcm7J/deTM3BqIM1Aa8ABkyB2zIcp6eR67xkeGQ15P1MSMpKPKCzlM+ M0mSHDbp7GzMcc2jxb2zDHAZY6O8d8heztu09VEXRfu7gmeDnwayiYhER1wI/OmlyF P+wXGLdNGBOFhIR2lFiRLSmKmN1lbdvE7XZAx6/QFumEio0Ie52TKfthAdAoEt+XJy K6PS4O+QUnX4ONKHG3TE7731oFH2T3bdPhfBKPJiwiZgfbqeBZX+G5XUFHojDyDkQk cPlQ/MFXcx0/Q== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/sFTXUR3ATz8hWmBj9hgrozHvewA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-sip-oauth-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, 30 Jun 2014 18:25:55 -0000 I think we are now suffering from not understanding one another, because we are too far into hypothetical space. Could you spin another version that uses sip 401/407? Then we can more easily discuss issues of how that works. Thanks, Paul On 6/30/14 1:39 PM, Rifaat Shekh-Yusef wrote: > > > > On Mon, Jun 30, 2014 at 1:12 PM, Paul Kyzivat > wrote: > > On 6/30/14 12:59 PM, Rifaat Shekh-Yusef wrote: > > May be it is my wording that is a bit confusing here. > > The server includes the Authenticate header in the challenge to > indicate > to the client which scheme it must use to provide user's > credentials in > the response. > In this case the server is not expecting the client to provide > it with > the user's credentials; instead it is expecting the client to > provide > the user's credentials to the authorization server. > > > ISTM there are two different credentials: > > - an auth code presented by the client to the proxy > - credentials presented to the auth server in order to get an auth code > > > So, yes, in this case the proxy is challenging the client, but I > do not > see the need to include the Authenticate header in the challenge. > > > There needs to be some way for the client to deliver the code to the > server. The Authorization header, with a new scheme, would be a > plausible way to do that. > > > Yes, and that is already described in the draft. > > The challenge then says that credentials (the token) using the new > scheme are required. > > What is the benefit of the proxy explicitly stating that in the challenge? > > Thanks, > Paul > > Regards, > Rifaat > > > > On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat > > >__> > wrote: > > On 6/28/14 6:26 AM, Rifaat Shekh-Yusef wrote: > > It would be good to know how the first REGISTER > response > interoperates > when there are other authentication mechanisms > present. > I'd expect a > 407 response with suitable Proxy-Authenticate > headers; the > grammar > allows a wide variety of authentication > challenges, and the > authorization server URL could be returned in one > of them, > while > challenges for different auth. methods could be in > others. > > The challenge-response mechanism is well-defined and allows > different > schemes to be used. > The current proposal uses the Digest scheme, but others > could be > used. > > But for the first REGISTER in the flow in section 3, > the 401 > should not > include an authenticate header as the proxy is not > challenging the > request, only a way to redirect the UA to the > authorization server. > > > Isn't the proxy saying: I refuse your request because I > require a > correct "code"? That seems like a challenge to me. > > It just happens to also include hints on where to go to get > a code. > > Thanks, > Paul > > ___________________________________________________ > sipcore mailing list > sipcore@ietf.org > > > https://www.ietf.org/mailman/____listinfo/sipcore > > > > > > >