From trac@tools.ietf.org Mon Aug 3 00:24:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D473A683F for ; Mon, 3 Aug 2009 00:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddMrH3Ip7ufR for ; Mon, 3 Aug 2009 00:24:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 9ECC13A6999 for ; Mon, 3 Aug 2009 00:24:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXruI-00085E-4k; Mon, 03 Aug 2009 00:24:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: leifj@mnt.se X-Trac-Project: oauth Date: Mon, 03 Aug 2009 07:24:30 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/4#comment:1 Message-ID: <068.f6ae8b2765be07a1661ebb9132959046@tools.ietf.org> References: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leifj@mnt.se, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:24:28 -0000 #4: Error Codes ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: authentication | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by leifj@mnt.se): My first question is what would happen to the ProblemReporting proposal - does it get republished as a standards-track I-D or will it stay an extension at oauth.net. I guess it would have to be a standards-track I-D if we want to be able to make normative references to it..? As for the proposal itself I've got some minor comments: - The text "Other values of oauth_problem MUST NOT be used. However, a Consumer SHOULD be prepared to receive other values, from a Service Provider that implements a future version of problem reporting." This feels inconsistent to me - isn't it better to apply the robustness principle and only say that "Consumers MUST be prepared to receive other values as Service Provders may implement later versions of this specification, however Consumers MUST silently ignore parameters they do not understand." In that spirit the oauth_parameters_rejected parameter might need to become oauth_parameters_ignored. - A range of values in oauth_acceptable_versions feels like a bad idea - who knows what type of strings will be thought appropriate for oauth versions in the future and comparison may not me meaningful. Just use a comma-separated list - we really shouldn't be defining that many version to make this a problem :-) - oauth_acceptable_timestamps: How could a sender (the use of sender/receiver gets confusing in the text btw) ever make use of that value? Is it to adjust the clock or just pick a timestamp in the range? I may just have misunderstood things... -- Ticket URL: oauth From trac@tools.ietf.org Mon Aug 3 00:34:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD523A68D1 for ; Mon, 3 Aug 2009 00:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oinC1GUe16hd for ; Mon, 3 Aug 2009 00:34:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E467A3A6D77 for ; Mon, 3 Aug 2009 00:33:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXs3C-0001Rt-Sv; Mon, 03 Aug 2009 00:33:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: esjewett@gmail.com, leifj@mnt.se X-Trac-Project: oauth Date: Mon, 03 Aug 2009 07:33:42 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/2#comment:2 Message-ID: <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: esjewett@gmail.com, leifj@mnt.se, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:34:25 -0000 #2: No Required Signature Method ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by leifj@mnt.se): Mandatory-to-implement discussions in the IETF have a bad history. Is there any reason not to mandate all three? Don't all implementations to date already implement all three or is any of the mechanisms in practice never implemented? -- Ticket URL: oauth From trac@tools.ietf.org Mon Aug 3 00:39:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F0F3A6D7D for ; Mon, 3 Aug 2009 00:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3XL+itYW7SO for ; Mon, 3 Aug 2009 00:39:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 7C7893A6AB4 for ; Mon, 3 Aug 2009 00:39:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXs8q-0001en-K7; Mon, 03 Aug 2009 00:39:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: esjewett@gmail.com, leifj@mnt.se X-Trac-Project: oauth Date: Mon, 03 Aug 2009 07:39:32 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/3#comment:2 Message-ID: <068.75d37c194b3663e1131705afb85e0df4@tools.ietf.org> References: <059.93566784ff77fdb326fb5f22b11c9b17@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <059.93566784ff77fdb326fb5f22b11c9b17@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: esjewett@gmail.com, leifj@mnt.se, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #3: Discovery Outline / Boundries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:39:32 -0000 #3: Discovery Outline / Boundries ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: web-delegation | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by leifj@mnt.se): What are the security implications of letting the request_auth and get_token URLs be derivable from the protocol exchange in this way? -- Ticket URL: oauth From eran@hueniverse.com Mon Aug 3 14:24:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928223A6BE1 for ; Mon, 3 Aug 2009 14:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwASziST3l8f for ; Mon, 3 Aug 2009 14:24:24 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 951393A698F for ; Mon, 3 Aug 2009 14:24:06 -0700 (PDT) Received: (qmail 2617 invoked from network); 3 Aug 2009 21:24:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Aug 2009 21:24:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 3 Aug 2009 14:24:02 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 3 Aug 2009 14:24:06 -0700 Thread-Topic: [OAUTH-WG] [oauth] #4: Error Codes Thread-Index: AcoUC3W6w/rq3zuLT6ulQO4BINiduQAdUDhg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783562D11@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> <068.f6ae8b2765be07a1661ebb9132959046@tools.ietf.org> In-Reply-To: <068.f6ae8b2765be07a1661ebb9132959046@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:24:25 -0000 We will need to write a new proposal which can be based on the problem repo= rting extension. But it will be part of the core spec(s). I don't think we = need to have it as an I-D. It is just a good reference (for the WG) to exis= ting work in the space. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of oauth issue tracker > Sent: Monday, August 03, 2009 12:25 AM > To: leifj@mnt.se > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes >=20 > #4: Error Codes > ---------------------------------+------------------------------------ > ---------------------------------+- > ----- > Reporter: eran@hueniverse.com | Owner: > Type: defect | Status: new > Priority: critical | Milestone: > Component: authentication | Version: > Severity: Active WG Document | Resolution: > Keywords: | > ---------------------------------+------------------------------------ > ---------------------------------+- > ----- >=20 > Comment(by leifj@mnt.se): >=20 > My first question is what would happen to the ProblemReporting=20 > proposal - does it get republished as a standards-track I-D or will=20 > it stay an extension at oauth.net. I guess it would have to be a=20 > standards-track I-D if we want to be able to make normative=20 > references to it..? >=20 > As for the proposal itself I've got some minor comments: >=20 > - The text >=20 > "Other values of oauth_problem MUST NOT be used. However, a Consumer =20 > SHOULD be prepared to receive other values, from a Service Provider=20 > that implements a future version of problem reporting." >=20 > This feels inconsistent to me - isn't it better to apply the=20 > robustness principle and only say that "Consumers MUST be prepared to=20 > receive other values as Service Provders may implement later versions=20 > of this specification, however Consumers MUST silently ignore=20 > parameters they do not understand." >=20 > In that spirit the oauth_parameters_rejected parameter might need to =20 > become oauth_parameters_ignored. >=20 > - A range of values in oauth_acceptable_versions feels like a bad=20 > idea > - > who knows what type of strings will be thought appropriate for oauth =20 > versions in the future and comparison may not me meaningful. Just use=20 > a comma-separated list - we really shouldn't be defining that many=20 > version to make this a problem :-) >=20 > - oauth_acceptable_timestamps: How could a sender (the use of =20 > sender/receiver gets confusing in the text btw) ever make use of that =20 > value? Is it to adjust the clock or just pick a timestamp in the=20 > range? I may just have misunderstood things... >=20 > -- > Ticket URL: > > oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Aug 3 14:24:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BBB28C1CE for ; Mon, 3 Aug 2009 14:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voSYyXkEPZgQ for ; Mon, 3 Aug 2009 14:24:56 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3C05F3A698F for ; Mon, 3 Aug 2009 14:24:56 -0700 (PDT) Received: (qmail 7503 invoked from network); 3 Aug 2009 21:24:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Aug 2009 21:24:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 3 Aug 2009 14:24:58 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 3 Aug 2009 14:25:02 -0700 Thread-Topic: [OAUTH-WG] [oauth] #2: No Required Signature Method Thread-Index: AcoUDNrnueziHYwPTfCw2ToBL8P4pQAc7VXg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783562D12@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> In-Reply-To: <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:24:57 -0000 They are not all implemented, and when they are, not consistently. A client= cannot assume any of the methods to be supported today. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of oauth issue tracker > Sent: Monday, August 03, 2009 12:34 AM > To: esjewett@gmail.com; leifj@mnt.se > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method >=20 > #2: No Required Signature Method > ---------------------------------+------------------------------------- > ----- > Reporter: eran@hueniverse.com | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: authentication | Version: > Severity: Active WG Document | Resolution: > Keywords: | > ---------------------------------+------------------------------------- > ----- >=20 > Comment(by leifj@mnt.se): >=20 > Mandatory-to-implement discussions in the IETF have a bad history. Is > there any reason not to mandate all three? Don't all implementations > to > date already implement all three or is any of the mechanisms in > practice > never implemented? >=20 > -- > Ticket URL: > > oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From leifj@sunet.se Wed Aug 5 00:32:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A8228C502 for ; Wed, 5 Aug 2009 00:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLx2FMXllMJ3 for ; Wed, 5 Aug 2009 00:32:26 -0700 (PDT) Received: from smtp.su.se (smtp2.su.se [130.237.164.53]) by core3.amsl.com (Postfix) with ESMTP id 007BA28C4F6 for ; Wed, 5 Aug 2009 00:32:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id E82BC5C0EB; Wed, 5 Aug 2009 09:32:20 +0200 (CEST) X-Virus-Scanned: by amavisd-new at av-in.su.se Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g4Q1CVaWskAc; Wed, 5 Aug 2009 09:32:20 +0200 (CEST) Received: from klapautius.localnet (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTPSA id 58D2481A16; Wed, 5 Aug 2009 09:32:20 +0200 (CEST) From: Leif Johansson Organization: SUNET To: oauth@ietf.org Date: Wed, 5 Aug 2009 09:32:17 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-14-generic; KDE/4.2.2; i686; ; ) References: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> <068.f6ae8b2765be07a1661ebb9132959046@tools.ietf.org> <90C41DD21FB7C64BB94121FBBC2E72343783562D11@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783562D11@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908050932.18183.leifj@sunet.se> X-Mailman-Approved-At: Wed, 05 Aug 2009 08:30:29 -0700 Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 07:32:27 -0000 On Monday 03 August 2009 23.24.06 Eran Hammer-Lahav wrote: > We will need to write a new proposal which can be based on the problem > reporting extension. But it will be part of the core spec(s). I don't think > we need to have it as an I-D. It is just a good reference (for the WG) to > existing work in the space. > The core specification can be multiple documents... but I agree that writing a new I-D based on this work is probably a good way forward. Keeping things in separate docs helps when you have multiple authors and we can always merge all aspects if the core spec into a single doc later should we want to (although I'm not sure we do). Cheers Leif From stpeter@stpeter.im Thu Aug 13 20:57:41 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5098D3A6971 for ; Thu, 13 Aug 2009 20:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0kHNUXEdehi for ; Thu, 13 Aug 2009 20:57:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6C81E3A69C0 for ; Thu, 13 Aug 2009 20:57:40 -0700 (PDT) Received: from squire.local (ip-216-17-182-239.rev.frii.com [216.17.182.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 59E5140343 for ; Thu, 13 Aug 2009 21:57:44 -0600 (MDT) Message-ID: <4A84E0B7.3030104@stpeter.im> Date: Thu, 13 Aug 2009 21:57:43 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: oauth@ietf.org References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> In-Reply-To: <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 03:57:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/3/09 1:33 AM, oauth issue tracker wrote: > Comment(by leifj@mnt.se): > > Mandatory-to-implement discussions in the IETF have a bad history. Is > there any reason not to mandate all three? Don't all implementations to > date already implement all three or is any of the mechanisms in practice > never implemented? Leif, it's not clear to me what you mean by "MTI discussions have a bad history". The idea behind MTI is that we define a baseline mechanism that all clients and servers are guaranteed to implement, which will help to improve interperability. Can you point to examples of MTI guidelines that have not improved interoperability? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqE4LcACgkQNL8k5A2w/vwxnwCeNiOmJnzzfBX3brX6rcP2GS6Y nt4AoMGE9CSBi6py5PLjQla6+UrwDFgN =BM7E -----END PGP SIGNATURE----- From leifj@mnt.se Fri Aug 14 14:18:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E293A6DAD for ; Fri, 14 Aug 2009 14:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-1.244, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVn5gwHKrp0W for ; Fri, 14 Aug 2009 14:18:34 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 331B13A6D3D for ; Fri, 14 Aug 2009 14:18:34 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so386626eye.31 for ; Fri, 14 Aug 2009 14:18:31 -0700 (PDT) Received: by 10.210.13.12 with SMTP id 12mr3628670ebm.98.1250284711276; Fri, 14 Aug 2009 14:18:31 -0700 (PDT) Received: from klapautius.localnet (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) by mx.google.com with ESMTPS id 5sm6819027eyh.46.2009.08.14.14.18.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Aug 2009 14:18:30 -0700 (PDT) From: Leif Johansson Organization: mnt.se To: oauth@ietf.org Date: Fri, 14 Aug 2009 23:18:27 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-14-generic; KDE/4.2.2; i686; ; ) References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> <4A84E0B7.3030104@stpeter.im> In-Reply-To: <4A84E0B7.3030104@stpeter.im> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908142318.27951.leifj@mnt.se> Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 21:18:35 -0000 On Friday 14 August 2009 05.57.43 Peter Saint-Andre wrote: > On 8/3/09 1:33 AM, oauth issue tracker wrote: > > Comment(by leifj@mnt.se): > > > > Mandatory-to-implement discussions in the IETF have a bad history. Is > > there any reason not to mandate all three? Don't all implementations to > > date already implement all three or is any of the mechanisms in practice > > never implemented? > > Leif, it's not clear to me what you mean by "MTI discussions have a bad > history". The idea behind MTI is that we define a baseline mechanism > that all clients and servers are guaranteed to implement, which will > help to improve interperability. Can you point to examples of MTI > guidelines that have not improved interoperability? > > Peter LDAP authentication mechanisms is an example - or HTTP dito for that matter! The problem is that quite often the choice of authentication mechanisms mostly hinges on the environment where the protocol is deployed. For instance LDAP in many "enterprisey" deployments use GSSAPI instead sasl plain+tls. GSSAPI isn't MTI for LDAP. Having a mandatory to implement mechanism for LDAP has neither helped (nor perhaps hindered) LDAP - imho. In practice an LDAP implementations need to implement *all* mechs in wide use today to be useful - GSSAPI (SASL GSSSAPI really), tls+SASL EXTERNAL, tls+plain - and a few more. I'm not saying MTI is bad - I'm just not convinced it helps much in practice. Cheers Leif From hubertlvg@gmail.com Mon Aug 17 03:30:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A402F3A6D80 for ; Mon, 17 Aug 2009 03:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mgYOU3xk9XK for ; Mon, 17 Aug 2009 03:30:11 -0700 (PDT) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by core3.amsl.com (Postfix) with ESMTP id 1ED633A67A6 for ; Mon, 17 Aug 2009 03:30:10 -0700 (PDT) Received: by fxm22 with SMTP id 22so2550793fxm.9 for ; Mon, 17 Aug 2009 03:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ppxUFG32NzQyDaMLT0DmD/5az7al03QIWXctcFekHL4=; b=J8cCGlORmCWwgpyF6BTQR/qIvZ9sdlaSrZ5Hm9IkvpLIE4wy6D+Jv5E+o7NKvwIE+O p6ZtMQNK8Q2+VC1tIsS3UM/MKf+mT1i0ZGx9Lf7tt+m9KiA/7ky4DqXZeCAf7QNUg1L/ A9sQtbnd+LgyL1kXW6Ox8GFVGfENTynF6MM1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=NAKKrMM3uNc3HWmo6BiWSgY351nWxgqdGkZaWXAUKHTWllDDo0WNpEPbPmlor+c4pF BLRO7ajb4py7ShvqiujwLMcMz4xWFAJZ5XIYFtrd0q/qLv17yepq5hl4wDF/GGda2znC tb+US+KCXl5VNWbc6PnB7gM6ZfglPTDqLfW24= MIME-Version: 1.0 Received: by 10.204.24.130 with SMTP id v2mr2573959bkb.33.1250505012514; Mon, 17 Aug 2009 03:30:12 -0700 (PDT) In-Reply-To: <200908142318.27951.leifj@mnt.se> References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> <4A84E0B7.3030104@stpeter.im> <200908142318.27951.leifj@mnt.se> Date: Mon, 17 Aug 2009 12:30:12 +0200 Message-ID: <6c0fd2bc0908170330i39d66458ia97e271d41e5d3a4@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 10:30:12 -0000 Another facet of this discussion is whether we should recommend/mandate other signature methods. Security experts (and I don't claim to be one) at my company highly recommend we look for stronger algos (any new protocol should support, at a minimum, HMAC-SHA256 and RSA-SHA256). Cipher suite agility, i.e. allowing implementations to move on to a newer cipher suites like SHA3 (when avail.) or ECC, should be considered too. Of course this will come at the cost of a slight increase in complexity of the protocol (to express signature capabilities or lack of support for a specific one for instance). Hubert On Fri, Aug 14, 2009 at 11:18 PM, Leif Johansson wrote: > On Friday 14 August 2009 05.57.43 Peter Saint-Andre wrote: >> On 8/3/09 1:33 AM, oauth issue tracker wrote: >> > Comment(by leifj@mnt.se): >> > >> > =A0Mandatory-to-implement discussions in the IETF have a bad history. = Is >> > =A0there any reason not to mandate all three? Don't all implementation= s to >> > =A0date already implement all three or is any of the mechanisms in pra= ctice >> > =A0never implemented? >> >> Leif, it's not clear to me what you mean by "MTI discussions have a bad >> history". The idea behind MTI is that we define a baseline mechanism >> that all clients and servers are guaranteed to implement, which will >> help to improve interperability. Can you point to examples of MTI >> guidelines that have not improved interoperability? >> >> Peter > > LDAP authentication mechanisms is an example - or HTTP dito for that > matter! > > The problem is that quite often the choice of authentication mechanisms > mostly hinges on the environment where the protocol is deployed. For > instance LDAP in many "enterprisey" deployments use GSSAPI instead > sasl plain+tls. GSSAPI isn't MTI for LDAP. Having a mandatory to implemen= t > mechanism for LDAP has neither helped (nor perhaps hindered) LDAP - imho. > > In practice an LDAP implementations need to implement *all* mechs in wide > use today to be useful - GSSAPI (SASL GSSSAPI really), tls+SASL EXTERNAL, > tls+plain - and a few more. > > I'm not saying MTI is bad - I'm just not convinced it helps much in pract= ice. > > =A0 =A0 =A0 =A0Cheers Leif > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From romeda@gmail.com Tue Aug 18 03:34:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666FD3A6B58 for ; Tue, 18 Aug 2009 03:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3TifHB+3+XZ for ; Tue, 18 Aug 2009 03:34:47 -0700 (PDT) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by core3.amsl.com (Postfix) with ESMTP id D1A763A676A for ; Tue, 18 Aug 2009 03:34:46 -0700 (PDT) Received: by bwz2 with SMTP id 2so2698927bwz.43 for ; Tue, 18 Aug 2009 03:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=VU46CTLqkbvnExxpzVwrwwhd3WzWXm1O6Wn4qv1azxI=; b=hhE99RJgq8kIGylWF0z7hpdwXIgGWXug1BikMq5ygoCE4ga1m28QkXO4m4Ce8y3ePR 4trm4bhFVOg2NL+IWhys0VftstDkSXCmM3DMsktJqeAIfEpHXlmDbWQXJTmiciErnx4/ ZSzMzPdBdhVrI5MbbRI0UHTNNtzAz9RKANLvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=asyrnOWyCIGhmBL+UzBCu83+cw6ENyc7XejrFhjQCsEjIOdj/hoOK5QKOujYx8AbYd MWUdyNJNWHH15eOugkw9uUd1ulz37uGcJP2amCZEjUiNmwPjB7OUwrEolckp+JK3VIam MCHLQpdaCDaGutZRL6/buFC6fAvqbFIuHuQKo= MIME-Version: 1.0 Received: by 10.204.32.206 with SMTP id e14mr3681449bkd.22.1250589818143; Tue, 18 Aug 2009 03:03:38 -0700 (PDT) In-Reply-To: <6c0fd2bc0908170330i39d66458ia97e271d41e5d3a4@mail.gmail.com> References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> <4A84E0B7.3030104@stpeter.im> <200908142318.27951.leifj@mnt.se> <6c0fd2bc0908170330i39d66458ia97e271d41e5d3a4@mail.gmail.com> From: Blaine Cook Date: Tue, 18 Aug 2009 11:03:18 +0100 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 10:34:48 -0000 2009/8/17 Hubert Le Van Gong : > Another facet of this discussion is whether we should recommend/mandate > other signature methods. Security experts (and I don't claim to be one) > at my company highly recommend we look for stronger algos (any new > protocol should support, at a minimum, HMAC-SHA256 and RSA-SHA256). > > Cipher suite agility, i.e. allowing implementations to move on to a newer > cipher suites like SHA3 (when avail.) or ECC, should be considered too. > Of course this will come at the cost of a slight increase in complexity > of the protocol (to express signature capabilities or lack of support for > a specific one for instance). OAuth in its existing form has this capability, specifically in the oauth_signature_method parameter. I know there was some debate at the IETF about the naming of that parameter, but the intent is to allow OAuth to keep up with changes to the crypto landscape without requiring protocol-level changes. b. From hubertlvg@gmail.com Tue Aug 18 04:07:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1693A6B9D for ; Tue, 18 Aug 2009 04:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WIskncdqFe8 for ; Tue, 18 Aug 2009 04:07:26 -0700 (PDT) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by core3.amsl.com (Postfix) with ESMTP id A6F3D3A680E for ; Tue, 18 Aug 2009 04:07:25 -0700 (PDT) Received: by bwz2 with SMTP id 2so2725410bwz.43 for ; Tue, 18 Aug 2009 04:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tEVGDhLt6gsCq6gUPhuCEwUbXq0a+EsNy2vQlu1WXw4=; b=YtLXbvJIHirEhcDQfkXSXwVMDAly8XMIflQZMl+7qB9PiL7/kgUqrVU2L7skw+7ZvH BZU4ZVwFES/ncAMQ9UaX0eTfIvMkuGepmYABYTckD+WC3B85MsG507R5/9UV34ab3RQX U/bgXKDXdkZ0aWFwFxL7JnS4wp/JFsHAeaTSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cxLw/3WzZqkh0xH6k9CZg4mk/jU2oZyBjJxZ8dfFV9/c3Syj37lRfklLdZBwpaYt6+ YP53digUz8fIOesK1AHvPI9hLwsZsCxcCfZu5xAoOkvH6ILNtB7HPzPYwk8PP19gKBlq WgJa8atYNjiSiRHSBQ6iVm72jIUkt+9U8MODc= MIME-Version: 1.0 Received: by 10.204.30.195 with SMTP id v3mr3626173bkc.46.1250591580725; Tue, 18 Aug 2009 03:33:00 -0700 (PDT) In-Reply-To: References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> <4A84E0B7.3030104@stpeter.im> <200908142318.27951.leifj@mnt.se> <6c0fd2bc0908170330i39d66458ia97e271d41e5d3a4@mail.gmail.com> Date: Tue, 18 Aug 2009 12:33:00 +0200 Message-ID: <6c0fd2bc0908180333n93de053q7d8dd452d61c59aa@mail.gmail.com> From: Hubert Le Van Gong To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 11:07:26 -0000 Agreed, but the Consumer is sort of fishing in the dark since it does not know whether the Service Provider (SP) , at the time of the request, will also support the same method. Moreover we don't have a standard way for the SP to say "I can't do method X but will accept Y or Z". We can always defer to the OOB initial introduction or some additional discovery step to sort things out but it might be better to have some minimal capability baked in the spec. Just my 2 cents. Hubert On Tue, Aug 18, 2009 at 12:02 PM, Blaine Cook wrote: > 2009/8/17 Hubert Le Van Gong : >> Another facet of this discussion is whether we should recommend/mandate >> other signature methods. Security experts (and I don't claim to be one) >> at my company highly recommend we look for stronger algos (any new >> protocol should support, at a minimum, HMAC-SHA256 and RSA-SHA256). >> >> Cipher suite agility, i.e. allowing implementations to move on to a newer >> cipher suites like SHA3 (when avail.) or ECC, should be considered too. >> Of course this will come at the cost of a slight increase in complexity >> of the protocol (to express signature capabilities or lack of support for >> a specific one for instance). > > OAuth in its existing form has this capability, specifically in the > oauth_signature_method parameter. I know there was some debate at the > IETF about the naming of that parameter, but the intent is to allow > OAuth to keep up with changes to the crypto landscape without > requiring protocol-level changes. > > b. > From lindner@inuus.com Tue Aug 18 13:23:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B139928C24E for ; Tue, 18 Aug 2009 13:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGZ6zQzePcZy for ; Tue, 18 Aug 2009 13:23:33 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 732323A63D3 for ; Tue, 18 Aug 2009 13:23:33 -0700 (PDT) Received: by ywh26 with SMTP id 26so5148062ywh.5 for ; Tue, 18 Aug 2009 13:23:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.92.5 with SMTP id u5mr6024132anl.102.1250627003284; Tue, 18 Aug 2009 13:23:23 -0700 (PDT) In-Reply-To: <6c0fd2bc0908180333n93de053q7d8dd452d61c59aa@mail.gmail.com> References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <068.81d64da2acecc6f176e017d76c9db059@tools.ietf.org> <4A84E0B7.3030104@stpeter.im> <200908142318.27951.leifj@mnt.se> <6c0fd2bc0908170330i39d66458ia97e271d41e5d3a4@mail.gmail.com> <6c0fd2bc0908180333n93de053q7d8dd452d61c59aa@mail.gmail.com> Date: Tue, 18 Aug 2009 13:23:23 -0700 Message-ID: From: Paul Lindner To: Hubert Le Van Gong Content-Type: multipart/alternative; boundary=001636ed6caa46fe690471704a46 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 20:23:34 -0000 --001636ed6caa46fe690471704a46 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adding supported signatures to the OAuth Problem Reporting extension might be one way to deal with this issue: http://wiki.oauth.net/ProblemReporting A response parameter like oauth_acceptable_signatures would suffice. On Tue, Aug 18, 2009 at 3:33 AM, Hubert Le Van Gong wrote: > Agreed, but the Consumer is sort of fishing in the dark since it does not > know > whether the Service Provider (SP) , at the time of the request, will > also support > the same method. Moreover we don't have a standard way for the SP to > say "I can't do method X but will accept Y or Z". > We can always defer to the OOB initial introduction or some additional > discovery step to sort things out but it might be better to have some > minimal > capability baked in the spec. > > Just my 2 cents. > > Hubert > > > On Tue, Aug 18, 2009 at 12:02 PM, Blaine Cook wrote: > > 2009/8/17 Hubert Le Van Gong : > >> Another facet of this discussion is whether we should recommend/mandate > >> other signature methods. Security experts (and I don't claim to be one) > >> at my company highly recommend we look for stronger algos (any new > >> protocol should support, at a minimum, HMAC-SHA256 and RSA-SHA256). > >> > >> Cipher suite agility, i.e. allowing implementations to move on to a > newer > >> cipher suites like SHA3 (when avail.) or ECC, should be considered too. > >> Of course this will come at the cost of a slight increase in complexity > >> of the protocol (to express signature capabilities or lack of support > for > >> a specific one for instance). > > > > OAuth in its existing form has this capability, specifically in the > > oauth_signature_method parameter. I know there was some debate at the > > IETF about the naming of that parameter, but the intent is to allow > > OAuth to keep up with changes to the crypto landscape without > > requiring protocol-level changes. > > > > b. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636ed6caa46fe690471704a46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adding supported signatures to the OAuth Problem Reporting extension might = be one way to deal with this issue:

http://wiki.oauth.net/ProblemReporting

A response parameter like oauth_acceptable_signatures w= ould suffice.

On Tue, Aug 18, 2009 at 3:3= 3 AM, Hubert Le Van Gong <hubertlvg@gmail.com> wrote:
Agreed, but the Consumer is sort of fishing= in the dark since it does not know
whether the Service Provider (SP) , at the time of the request, will
also support
the same method. Moreover we don't have a standard way for the SP to say "I can't do method X but will accept Y or Z".
We can always defer to the OOB initial introduction or some additional
discovery step to sort things out but it might be better to have some minim= al
capability baked in the spec.

Just my 2 cents.

Hubert


On Tue, Aug 18, 2009 at 12:02 PM, Blaine Cook<romeda@gmail.com> wrote:
> 2009/8/17 Hubert Le Van Gong <hubertlvg@gmail.com>:
>> Another facet of this discussion is whether we should recommend/ma= ndate
>> other signature methods. Security experts (and I don't claim t= o be one)
>> at my company highly recommend we look for stronger algos (any new=
>> protocol should support, at a minimum, HMAC-SHA256 and RSA-SHA256)= .
>>
>> Cipher suite agility, i.e. allowing implementations to move on to = a newer
>> cipher suites like SHA3 (when avail.) or ECC, should be considered= too.
>> Of course this will come at the cost of a slight increase in compl= exity
>> of the protocol (to express signature capabilities or lack of supp= ort for
>> a specific one for instance).
>
> OAuth in its existing form has this capability, specifically in the > oauth_signature_method parameter. I know there was some debate at the<= br> > IETF about the naming of that parameter, but the intent is to allow > OAuth to keep up with changes to the crypto landscape without
> requiring protocol-level changes.
>
> b.
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001636ed6caa46fe690471704a46-- From leifj@mnt.se Fri Aug 21 15:32:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44F23A69EA for ; Fri, 21 Aug 2009 15:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SB6hjSXUQi7 for ; Fri, 21 Aug 2009 15:32:09 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id 95A3D3A6359 for ; Fri, 21 Aug 2009 15:32:09 -0700 (PDT) Received: by ewy2 with SMTP id 2so1134936ewy.43 for ; Fri, 21 Aug 2009 15:32:09 -0700 (PDT) Received: by 10.210.142.6 with SMTP id p6mr1781518ebd.69.1250893928777; Fri, 21 Aug 2009 15:32:08 -0700 (PDT) Received: from klapautius.localnet (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) by mx.google.com with ESMTPS id 24sm643115eyx.23.2009.08.21.15.32.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Aug 2009 15:32:06 -0700 (PDT) From: Leif Johansson Organization: mnt.se To: oauth@ietf.org Date: Sat, 22 Aug 2009 00:32:03 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; ) References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> <6c0fd2bc0908180333n93de053q7d8dd452d61c59aa@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908220032.03571.leifj@mnt.se> Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 22:32:10 -0000 On Tuesday 18 August 2009 22.23.23 Paul Lindner wrote: > Adding supported signatures to the OAuth Problem Reporting extension might > be one way to deal with this issue: > http://wiki.oauth.net/ProblemReporting > > A response parameter like oauth_acceptable_signatures would suffice. A negotiation like that might be vulnerable to a downgrade attack - i.e when an attacker is able to convince a client to settle for a less secure mechanism by modifying the list of mechanisms. In general the server would have to confirm the list of mechanisms in an authenticated message and the client compare the unauthenticated list to the authenticated list. Cheers Leif From stpeter@stpeter.im Thu Aug 27 15:18:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214ED3A6EBE for ; Thu, 27 Aug 2009 15:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzsnvAlPPBBv for ; Thu, 27 Aug 2009 15:18:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9E9433A6EB4 for ; Thu, 27 Aug 2009 15:18:34 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 281B64007B for ; Thu, 27 Aug 2009 16:18:41 -0600 (MDT) Message-ID: <4A97063F.2030703@stpeter.im> Date: Thu, 27 Aug 2009 16:18:39 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: [oauth] Re: HTTP response for bad oauth_verifier?] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 22:18:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. - -------- Original Message -------- Subject: [oauth] Re: HTTP response for bad oauth_verifier? Date: Thu, 27 Aug 2009 13:28:23 -0600 From: Peter Saint-Andre Reply-To: oauth@googlegroups.com To: oauth@googlegroups.com References: <47651285-a337-425a-9e12-dc32c89bae41@p36g2000prn.googlegroups.com> http://wiki.oauth.net/ProblemReporting has timestamp_refused (and also verifier_invalid), but it unclear about the mapping between those more specific conditions and the generic HTTP conditions. IMHO this needs to be clarified in draft-ietf-oauth-authentication as the specs are worked on in the Oauth WG: http://tools.ietf.org/html/draft-ietf-oauth-authentication-01 http://tools.ietf.org/wg/oauth/ Peter On 8/22/09 10:24 PM, Doug Kaye wrote: > Same question for bad timestamps. The spec (paragraph 10) says > timestamps must be >= previous timestamps but there's no HTTP 400/401 > string for this. > > On Aug 22, 7:59 pm, Doug Kaye wrote: >> Spec 6.3.2 (service provider processing of access token request) says >> to return an HTTP error if the oauth_verifier is bad. But Spec >> paragraph 10 indicates neither whether a 400 or 401 should be returned >> nor an appropriate text string. What is expected? - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en - -~----------~----~----~----~------~----~------~--~--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqXBj8ACgkQNL8k5A2w/vyChgCeKu3kj7p2gmYsd0FKLUhG4A+4 IYgAoNfxVruEehb97vHc7SIaVbFeYl9q =+NhJ -----END PGP SIGNATURE-----