From nobody Thu Dec 1 02:30:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2C129624 for ; Thu, 1 Dec 2016 02:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKAqmnaQv7DP for ; Thu, 1 Dec 2016 02:30:39 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1DDF12961C for ; Thu, 1 Dec 2016 02:30:38 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id b14so167889534lfg.2 for ; Thu, 01 Dec 2016 02:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=FoKbMBQgrhwSaVYaiTgowbsBAIe4vXCx1pKJymA07ck=; b=iJnIg3FrvucqEEA17+vUF1+jq5zZLf1NcXt5PHd1ysXCWOKp3mu44/ldMXt95+twQO I94Bf6QFF+IkFMgXq6HZSF3RWlniKQKmW8ljZbeTfxAxIy+9zJ1F/WWH+vMNamuuLmA0 LA6TAjzo7u40h5A9253rTVIRJEFV9Oy3mkhXxHhwDeNcyLgO8vWM718xp4gJ62hwf+eZ SoJznbAgIkbrMvtrZ9fw+zP9Rv1d5uwzzlxsGzA0rikMLCaADy/5k9hRgyki4iuZKOF4 oqOzt2IbIWf7xX2eaf9ZErJ9KOVvJDx8O1JxcK1YvjrHDvn0mCggGLkc5R7GW0bbRGFI 5lJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FoKbMBQgrhwSaVYaiTgowbsBAIe4vXCx1pKJymA07ck=; b=Qc4k4rm1PKFtQhXDUT4z/9m7Rzo+lq+cjzebZGPQsWALGnGuS5BpTUclzI/raBpjni M6+fp3N+GvW6KGC1c63S32LM4TvWDaPKdvwVBwvl0b2cB/PQlu68zU9hPmz5753mmMuX I7keIwXa3lL324g6aCuZhtvUO17qK7TSPDOHVSuWhpwsQyF3mmvIWuKyCcNd3Ijnm5kG EoETPOtjkxkkzxJbnKybAt+NSsfIGufC7JdzWNhDmLTNhFKzDZPC/GuUKrBF2Oh9zR2M Nm9w0pdb3APv8cabfK0nvVHz+GVL6zHnjwN99uIcI9/Pax0XBq1+JQb1Cd3t7p3ctasK huHg== X-Gm-Message-State: AKaTC02lIXK0FObFDghty0REKaUSeDPvPxeyxlSxS34Rlf/8aMEJ+vVB1wXPqLVDWKrqYw== X-Received: by 10.46.72.2 with SMTP id v2mr12075898lja.67.1480588236602; Thu, 01 Dec 2016 02:30:36 -0800 (PST) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id v26sm15199137lja.30.2016.12.01.02.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 02:30:35 -0800 (PST) To: John Bradley , Justin Richer References: <6c46d3a4-ad0d-3b49-7a15-7532634702e9@gmail.com> From: Sergey Beryozkin Message-ID: Date: Thu, 1 Dec 2016 10:30:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6c46d3a4-ad0d-3b49-7a15-7532634702e9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 10:30:41 -0000 Hi, We'll experiment with starting supporting a "resource_uris" extension array property - the name is based on a 'resource' indicator property from the resource indicators draft, with a '_uris' added given that many dynamic registration properties have similar suffixes Cheers, Sergey On 29/11/16 10:49, Sergey Beryozkin wrote: > Hi John, All > > I've been alway thinking that the reason an audience can be an array (as > indicated for ex by the JWT spec, etc) is because a client application > may need to talk to more than one RS in order to complete a single > action for the current user (ex, the client will not talk to either RS1 > or RS2 but first to RS1 and then will complete the action by talking to > RS2). > > Why else would a JWT access token have an array of audience values ? > https://tools.ietf.org/html/rfc7519#section-4.1.3 > > I agree the resource indicators can help on its own - in case no > audiences for a given client have been pre-registered or as you > suggested - to point to a specific resource at the runtime, with this > (resource) URI being validated against the pre-registered values. > > But also, pre-registering a single audience during the client > registration (dynamic or static) can minimize the need to use the > resource indicators at the runtime. > > I did not quite understand what you were explaining about registering > RSs with the client - I guess that client will know in advance which > RS(s) it will need to talk to do its work, > > Many thanks, Sergey > > > > > On 28/11/16 22:58, John Bradley wrote: >> To make something like this work with a loose coupling between the RS >> and AS the format of the AT would also need to be specified. >> >> To this point the WG has avoided standardizing AT. >> >> Most AS probably believe they know what RS the token is going to be >> used at based on scopes. >> Taking those tokens and using them at other RS is arguably at-least >> out of scope or arguably not allowed by the current specs. >> >> People are perhaps abusing the specs and sending AT to RS that are not >> properly audienced and can be replayed between RS. >> This is really bad from a security perspective with bearer tokens. >> >> I do however see a valid use case. >> >> Registering RS with the client is not a bad idea, however if you >> register more than one without the client saying at runtime what RS >> the token is for they can still be replayed. >> The client depending on design could still be tricked by a RS or >> something else to get a token audienced to a different RS if the AS >> dosen't know where the client is sending the token. >> >> I don’t think registering RS gets around the need for the resource >> indicator draft >> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators >> >> Typically we have thought about a tight coupling between the RS and >> AS, but now it seems people are putting more of the >> intelligence/burden on the the client. >> >> in a more dynamic system the RS might provide a list of AS that it >> accepts tokens form and the client might dynamically register with one >> of them. >> >> I suspect Sergey’s AS is doing something in between. >> >> I am hesitant to pick off just dynamic registration as there are a >> number of interrelated issues that need to be thought through to >> prevent security issues. >> >> John B. >> >> >> >> >> >> >>> On Nov 28, 2016, at 3:47 PM, Justin Richer wrote: >>> >>> I would consider that a totally reasonable extension. You will need >>> to define what the behavior is if the client doesn’t provide a value >>> for that field: is there a default? Are there no resources available >>> to the client? >>> >>> — Justin >>> >>>> On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin >>>> wrote: >>>> >>>> Hi All >>>> >>>> Our AS allows for the manual client registration with the UI >>>> offering an option to assign the audience/resource URIs to a given >>>> Client registration with all the associated future access tokens >>>> inheriting them. >>>> >>>> The client will not have to follow the resource indicator >>>> registration as recommended at [1] - the administrator who registers >>>> the clients sets the audiences. >>>> >>>> We'd like to achieve the same with the dynamic client registration >>>> but my colleague noted the client metadata in the dynamic >>>> registration request has no 'audience' property. >>>> >>>> We will consider supporting either an 'audience' or 'resource' >>>> property - does it sound reasonable ? >>>> >>>> By the way, as far as [1] is concerned, should a 'resource' property >>>> support an array of audiences ? (To support a case a client needed >>>> to talk to several RSs to complete a given action) >>>> >>>> Thanks, Sergey >>>> >>>> [1] >>>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > From nobody Fri Dec 9 11:54:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DF7129634 for ; Fri, 9 Dec 2016 11:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odF5fNnU_EZe for ; Fri, 9 Dec 2016 11:54:51 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EA412969E for ; Fri, 9 Dec 2016 11:54:50 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id f82so36606510wmf.1 for ; Fri, 09 Dec 2016 11:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version; bh=2I2aOtol1yjfffmuxlEAP+jEvVb4JRt4QOsDOHSbWos=; b=CAT5Z3VD7QgLqoIAlccuBDHS2/svIJ4JO9L/TFnE5anaTlGhStOizI3mK9EXfKSCvf GLm75/17ZxKwAor1J0xcqlh3l9ZrNIBREje6T1JrgyY/pL3SuiPlXqtULVUbIpxPeW8r UnlAtTySwrHVcrF0pVN+I8OKFfd977d6R2O9051zWQxLF1/I6ee+9EMAneUDghMmn0FG tp7KwC43E00yr9A6G8T/ykeybeNTTGov2LDLNEYMx4gAcEC/BVPe0k7jxa+6VgrHgX3V P1kwxfCRgIUQl1lVjE21/rjGvXk1ldkr3NNikDnPnDSiLStC5NRh3ByyQAifsLoy/Tx4 xV6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=2I2aOtol1yjfffmuxlEAP+jEvVb4JRt4QOsDOHSbWos=; b=nHYNZt1JMhTDObu/Os++8k5XvFHZ3BtfWuDqjDFkJBQFc0VPrl97sHLcBZakhnPuI2 zWAgH9SLAKl8ZtelxERXPhhGDhukOzvekSm14CnUyl3mYezXta4TJZ7mOSyuhHdnrV9J woCXNXlwpqaSYjdtXeiyGeZj6ub7EKNXSls7c0tf69JQt04Ybw29MOUpJkTLG+9NPHpf Vu/mTRPyN2Rag5LfAjf0/zZiY9Fc0jP3J0CYJUCIX8H3NGWwMQRri2AMCSg5c5PXPM3R eY/al7vXwg6nb9i8AMaitdGxkJ3kb4kqNrOcryCRFLyFgVzIFpdlK1AlUteor8JJLwFa 1M6w== X-Gm-Message-State: AKaTC03AKP/u4X50t0H+uoC1aRiVp0Y+heBRbga8oGjpQaEf/Sdd6H3XVLEwNF+0vX1/2Lzm X-Received: by 10.28.137.81 with SMTP id l78mr34552wmd.36.1481313288946; Fri, 09 Dec 2016 11:54:48 -0800 (PST) Received: from heembo.local (36.42.158.77.rev.sfr.net. [77.158.42.36]) by smtp.googlemail.com with ESMTPSA id l67sm22087630wmf.20.2016.12.09.11.54.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 11:54:48 -0800 (PST) To: OAuth WG , Torsten Lodderstedt From: Jim Manico Message-ID: <523660d6-b535-4877-2653-78be3c01b881@manicode.com> Date: Fri, 9 Dec 2016 20:54:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------36619E6CAF0B4B16AAEECC45" Archived-At: Subject: [OAUTH-WG] OAuth Tokens and URI's X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 19:54:53 -0000 This is a multi-part message in MIME format. --------------36619E6CAF0B4B16AAEECC45 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Torsten, The https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/= ?include_text=3D1 guide you are working on is a special kind of magic. Thank you for taking the time to write this very important document. When it comes to 2.2.1, I see your great suggestion to prevent referrer leakage. These defenses are very important, and I appreciate how clearly you laid these out. But I think they skip the really core problem that web security solutions must embrace - which I believe to be, /do not put sensitive data in URL/GET parameters/. This goes all the way back to RFC 2616 #9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval" which I feel implies "should not do anything dangerous" including transport sensitive data. OAuth 2 goes pretty wild - all the way - with putting very sensitive tokens in URIs/URLs and I have seen some solutions that break the "standard" and POST/PUT/PATCH when they can, keeping tokens out of POST actions, URL's and similar. Is this worth discussing? Thank you again for this very important and well written document. Aloha from Hawaii, --=20 Jim Manico Manicode Security https://www.manicode.com --------------36619E6CAF0B4B16AAEECC45 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Torsten,

The https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1 guide you are working on is a special kind of magic. Thank you for taking the time to write this very important document.

When it comes to 2.2.1, I see your great suggestion to prevent referrer leakage. These defenses are very important, and I appreciate how clearly you laid these out.

But I think they skip the really core problem that web security solutions must embrace - which I believe to be, do not put sensitive data in URL/GET parameters. This goes all the way back to RFC 2616 #9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval" which I feel implies "should not do anything dangerous" including transport sensitive data.

OAuth 2 goes pretty wild - all the way - with putting very sensitive tokens in URIs/URLs and I have seen some solutions that break the "standard" and POST/PUT/PATCH when they can, keeping tokens out of POST actions, URL's and similar.  Is this worth discussing?

Thank you again for this very important and well written document.

Aloha from Hawaii,
 
-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------36619E6CAF0B4B16AAEECC45-- From nobody Fri Dec 9 11:58:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5BB129548 for ; Fri, 9 Dec 2016 11:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3OsDUQNMxzZ for ; Fri, 9 Dec 2016 11:58:47 -0800 (PST) Received: from mail-wj0-x229.google.com (mail-wj0-x229.google.com [IPv6:2a00:1450:400c:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BBC1296A7 for ; Fri, 9 Dec 2016 11:58:46 -0800 (PST) Received: by mail-wj0-x229.google.com with SMTP id tg4so23204134wjb.1 for ; Fri, 09 Dec 2016 11:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Umql7fr5QS+X5mq/su4MQqGwXYTrh+nWU+MxtuelDsc=; b=L2qOXwZn5LASSOMlxaiUAWdYqhvdObthfnlZzFliutdNeEcGv4eKM0V+f75ULMvuCL bgiZj/oZBlUNJcCrV55MMOh2xGgq1z+kaByzHEZc70WYK6IgXfq+uOeqnyUMQll9+y78 f7GF30Fns6A4Uh+BFjYlx67Jl9YOz9eE2X6Y207dP0Ea20vnayA5C6d7fnCXQnKNzOp9 pllQkflgpAkWOl3m3BulVCIiVilOzwYqH8a8RywZRaP39qOj4s+retINrl2pfQOA+W1d Dxaj6qFvsNNrEnUtunrfAH42txWXyCMCd4DYo2SVaVdrGmeauVdTKHJE+j1n7bw9Z7h/ z0Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Umql7fr5QS+X5mq/su4MQqGwXYTrh+nWU+MxtuelDsc=; b=Dg8plJzv45s7h5GicWcBM8XsUq8Vnz57hhMockig3h32eIICE+QQ5uBdzws2DvZGU6 +XRFvDstPqNbxyltmWmOpUuslmt2In+jcOde4r/eJZ4aKGVNH8a1HmhmCUP/BIzvTzAC hlpjdT/UTwJY/U4/t0j92WpgWJNiLZcWo7zdSKAF3y+VV8hnrE2Rb5p0mSEOQKJq3aAF OLvsnxSGEZhOOmZ3CJtynoPcZ9cGeTDwCpqSgWNR0qXtyEunt7jN/8x4JM2Mg2NBPDCS c/nrnNuJLpeNnyzL2Ez1Tc8Ximb/ILck2g0L8Erq1cWIXBBFdXc6dTuyeKmVqua6+rD3 crnQ== X-Gm-Message-State: AKaTC00CqEGHHJGlh9UTUa2ZTsvTqSSt8U/gVJJsu41h0C8u9LfscGxDOZyMxlZbIbmm1NbT X-Received: by 10.194.246.170 with SMTP id xx10mr50877841wjc.174.1481313525304; Fri, 09 Dec 2016 11:58:45 -0800 (PST) Received: from heembo.local (36.42.158.77.rev.sfr.net. [77.158.42.36]) by smtp.googlemail.com with ESMTPSA id l6sm22196203wmd.5.2016.12.09.11.58.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 11:58:44 -0800 (PST) To: OAuth WG , Torsten Lodderstedt References: <523660d6-b535-4877-2653-78be3c01b881@manicode.com> From: Jim Manico Message-ID: <583e6e3c-51dd-db2c-6e41-cb8255ff45d1@manicode.com> Date: Fri, 9 Dec 2016 20:58:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <523660d6-b535-4877-2653-78be3c01b881@manicode.com> Content-Type: multipart/alternative; boundary="------------8B499BBEF4382A0D107CEC57" Archived-At: Subject: Re: [OAUTH-WG] OAuth Tokens and URI's X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 19:58:49 -0000 This is a multi-part message in MIME format. --------------8B499BBEF4382A0D107CEC57 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ... One more note. You mentioned in this section... o Use form post mode instead of redirect for authorization response .. This might be worth expanding on./Use form post and keep data OUT OF THE ACTION/ (which is essentially the same as a GET). Safe transport of tokens includes well configured HTTPS, POST and other verbs, and data being the body of the request, not in the action of a form. Fair? (And sorry, I missed this one the first time around) Aloha, Jim On 12/9/16 8:54 PM, Jim Manico wrote: > Torsten, > > The > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1 > guide you are working on is a special kind of magic. Thank you for > taking the time to write this very important document. > > When it comes to 2.2.1, I see your great suggestion to prevent > referrer leakage. These defenses are very important, and I appreciate > how clearly you laid these out. > > But I think they skip the really core problem that web security > solutions must embrace - which I believe to be, /do not put sensitive > data in URL/GET parameters/. This goes all the way back to RFC 2616 > #9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of > taking an action other than retrieval" which I feel implies "should > not do anything dangerous" including transport sensitive data. > > OAuth 2 goes pretty wild - all the way - with putting very sensitive > tokens in URIs/URLs and I have seen some solutions that break the > "standard" and POST/PUT/PATCH when they can, keeping tokens out of > POST actions, URL's and similar. Is this worth discussing? > > Thank you again for this very important and well written document. > > Aloha from Hawaii, > -- > Jim Manico > Manicode Security > https://www.manicode.com -- Jim Manico Manicode Security https://www.manicode.com --------------8B499BBEF4382A0D107CEC57 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

... One more note. You mentioned in this section...

   o  Use form post mode instead of redirect for authorization response

.. This might be worth expanding on. Use form post and keep data OUT OF THE ACTION (which is essentially the same as a GET). Safe transport of tokens includes well configured HTTPS, POST and other verbs, and data being the body of the request, not in the action of a form. Fair?

(And sorry, I missed this one the first time around)

Aloha, Jim

On 12/9/16 8:54 PM, Jim Manico wrote:
Torsten,

The https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1 guide you are working on is a special kind of magic. Thank you for taking the time to write this very important document.

When it comes to 2.2.1, I see your great suggestion to prevent referrer leakage. These defenses are very important, and I appreciate how clearly you laid these out.

But I think they skip the really core problem that web security solutions must embrace - which I believe to be, do not put sensitive data in URL/GET parameters. This goes all the way back to RFC 2616 #9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval" which I feel implies "should not do anything dangerous" including transport sensitive data.

OAuth 2 goes pretty wild - all the way - with putting very sensitive tokens in URIs/URLs and I have seen some solutions that break the "standard" and POST/PUT/PATCH when they can, keeping tokens out of POST actions, URL's and similar.  Is this worth discussing?

Thank you again for this very important and well written document.

Aloha from Hawaii,
 
-- 
Jim Manico
Manicode Security
https://www.manicode.com

-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------8B499BBEF4382A0D107CEC57-- From nobody Sun Dec 11 16:33:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAF41297CA; Sun, 11 Dec 2016 16:33:10 -0800 (PST) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTMgsbZCehUt; Sun, 11 Dec 2016 16:33:08 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629D912953A; Sun, 11 Dec 2016 16:33:08 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id a20so7838615wme.2; Sun, 11 Dec 2016 16:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=x5nr8dNoftZuu6a25ZwnCH+Bzzhag+gJJCgKLOQY8ck=; b=P0C/IQfe/iWmk0ilmrm3ecTWYGa4RY9lEYmMOHGOASvwt51KfGhUxwYdgE+bzPmR+R ODyQaiPjgy+wbwTbw+IHe16l1Kw20KNmzVQBQ9el70Rrg2q8eO3wFnQlRFKHKn/NpIbg E6abTBg3izAeqHz0qGHyJ46Mf/4JxUxknoKunMO+0PqSUGHki3x10E41Scr5f0RegGfy FrPnHc2kXIAN2BvjicKlQMAYn3ITRmPL7bFttcOvCoaMiWPeNqqT4SZTqHZr7GxgIz4a QkB3GYln02uuVnuV9Q/2iMOD7RpWIjpSf/1cZbY0HrjX5uaqcIXGEivcVGpdbKtxcLoG uDHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x5nr8dNoftZuu6a25ZwnCH+Bzzhag+gJJCgKLOQY8ck=; b=U7boBMoAaYIdAldwiAU/2gSWszlBtbmeYbwjCMbMdSC4VRXlva439lYg31gpMpDzYD CnmwjG+f4jNyOYrpKJQawDW9XDz0F+kBMCs8koF4XCmzwY+IglVeaZHFZ8kZbQP8+uYF dfH+i9+zYRltpQT6N49YkYRJcWbJ1fcXMLokS4WjvAq24qL/Ky2mV7kHyTgsecUCSj2O xHLruHPjGUdgxkL5w4rUpxOvFXP6bw9ykQew0fbCLchNvIvfkXj43ZgrmBXlTMDsYDxn hqsPWGNXIVnbmT+ZpVh0yWUwgcl+XqA6ikDEfuaujxJ3jR+nZ1LgfdAgTtjdQ7SneNg3 rAzQ== X-Gm-Message-State: AKaTC01MAxXHTU7I5KDuembX6h30PF+awfNxZo9ER9X5+RpVhgZM+/z6JFy7/YMw6Sd9gWk4D6/zn7kbpoBYcA== X-Received: by 10.28.166.208 with SMTP id p199mr6593955wme.27.1481502786934; Sun, 11 Dec 2016 16:33:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.129.74 with HTTP; Sun, 11 Dec 2016 16:33:06 -0800 (PST) From: Leads Zone Date: Mon, 12 Dec 2016 06:33:06 +0600 Message-ID: To: glorialevell glorialevell , The Guardian , leadszoneusa , leadszoneusa , leadszoneusa , Louise Meyers , oauth-request@ietf.org, OAuth@ietf.org, Willis Jones Content-Type: multipart/alternative; boundary=94eb2c12cad05960a505436b3f11 Archived-At: Subject: [OAUTH-WG] Craigslist posting and resume is available here for sale. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 00:33:10 -0000 --94eb2c12cad05960a505436b3f11 Content-Type: text/plain; charset=UTF-8 -- Craigslist leads generation here Posting category : ##Jobs ##Housing ##customer- services ##General-labor ##Gigs-labor ##Personal advertisement for sell. Connect with us : skype id : leads.zone outlook id: craigslist_leads@outlook.com yahoo Id: craigslist_leads@yahoo.com Gmail Id : leadszoneusa@gmail.com --94eb2c12cad05960a505436b3f11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


--
Craig= slist leads generation here


Posting category :


=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0##Jobs=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0##Housing=C2=A0
= =C2=A0 ##customer- services
=C2=A0 ##General-labor
=C2=A0 ##Gigs-labor
= =C2=A0 ##Personal advertisement for sell.


Connect with us :

skype id : = =C2=A0leads.zone


--94eb2c12cad05960a505436b3f11-- From nobody Wed Dec 21 05:37:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB6A1296AB for ; Wed, 21 Dec 2016 05:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJyGhhV0FXsU for ; Wed, 21 Dec 2016 05:37:19 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 6DF7712959D for ; Wed, 21 Dec 2016 05:37:14 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6DA097803A4 for ; Wed, 21 Dec 2016 14:37:12 +0100 (CET) To: oauth@ietf.org References: From: Denis Message-ID: <97ba9e08-6179-3157-1017-c616c42ba64f@free.fr> Date: Wed, 21 Dec 2016 14:37:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E3D0D6DEF50FB8617116055" Archived-At: Subject: [OAUTH-WG] Comments on draft-ietf-oauth-token-binding-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 13:37:22 -0000 This is a multi-part message in MIME format. --------------9E3D0D6DEF50FB8617116055 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit There has been a WGLC in the Token Binding (tokbind) WG about the following documents: draft-ietf-tokbind-protocol draft-ietf-tokbind-https draft-ietf-tokbind-negotiation I have posted the following comments: This set of documents failed to meet the terms of references of the WG charter. It is not resistant to the ABC attack (Alice and Bob collusion attack). In this attack Bob who is older than 18 colloborates with Alice and transmits a token to Alice who is only 14 so that she can demonstrate to a RS that she is older than 18. This kind of attack is not even mentionned in the security considerations section. ======================================================================== There are two options: *Option A*: drop this series of documents, i.e. : draft-ietf-tokbind-protocol draft-ietf-tokbind-https draft-ietf-tokbind-negotiation or ** *Option B*: clearly mention that the ABC attack cannot be countered using TLS binding. In case, the latter decision would be taken by the tokbind WG, I have proposed a few text replacements. *1 - *In *draft-ietf-tokbind-protocol*, change the abstract in the following way (and modify the content of the document in accordance): This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications tocreate long-lived, uniquely identifiable TLS [RFC5246 ] bindingsspanning multiple TLS sessions and connections.Applications arethen enabled to cryptographically bind security tokens to the TLSlayer. *However, the binding a security token to a TLS connection **is unable to counter collaboration attacks between two clients **since one client can compute the necessary information for the **other client without the need to release his key(s) to the other **client.For an effective protection against collaboration attacks, **an appropriate format of the security token, together with an **appropriate validation of some fields of it, must be used.*To protect privacy, the Token Binding identifiers are only transmitted encrypted and can be reset by the user at any time. Also the introduction states: (...) In order to successfully export and replay a bound security token, the attacker needs to also be able to export the client's private key, which is hard to do in the case of the key generated in a secure hardware module.Proposed replacement This should be replaced with: (...) *In order to successfully export and replay a bound security token, **a client does not need to export the client's private**key, since it can perform all the necessary computations in the **case of a collaboration attack. * *2 -* In *draft-ietf-tokbind-https* add two additional paragraphs in the abstract (and modify the content of the document in accordance): Abstract This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such ascookies and OAuth tokens) to TLS [RFC5246 ] connections. We describe both _first-party_ and _federated_ scenarios.In afirst-party scenario, an HTTP server is able to cryptographicallybind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server.Such bound security tokens are protected from misuse since the server can generally detect if they are replayedinappropriately, e.g., over other TLS connections.*However, the binding a security token to a TLS connection is **unable to counter collaboration attacks between two clients since **one client can compute the necessary information for the other **client without the need to release his key(s) to the other client. For an effective protection against collaboration attacks, an **appropriate format of the security token, together with an **appropriate validation of some fields of it, must be used.*Federated token bindings, on the other hand, allow servers tocryptographically bind security tokens to a TLS connection that theclient has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token BindingProtocol [I-D.ietf-tokbind-protocol ] In section 7.1, change the text in the following way: 7.1. Security Token Export andReplayThe goal of the Federated Token Binding mechanisms is to preventattackers from exporting and replaying tokens used in protocols between the client and Token Consumer, thereby impersonatinglegitimate users and gaining access to protected resources.Boundtokens can still be replayed by malware present in the client. *They can also be exported and re-used when a client collaborates **with another client.In order to export the token to another **machine and successfully use it, a client may export the **corresponding private key to the other client or may perform all **the necessary computations for the other client without exporting **the corresponding private**.Protecting the Token Binding private **key, e.g. in a hardware security module that prevents key export is **a good practice, but in such a case, it is inefficient to counter **the clients collaboration attack.* *3 - draft-ietf-oauth-token-binding-01* is based on the same foundations and hence is suject to the ABC attack. The same kind of decision is facing the OAuth WG: *Option A*: drop draft-ietf-oauth-token-binding. or ** *Option B*: clearly mention that the ABC attack cannot be countered using TLS binding. In case, the latter decision would be taken by the OAuth WG, the abstract should be changed (and the content of the document should be modified in accordance). The current abstract states: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens and Refresh Tokens. This cryptographically binds these tokens to the TLS connections over which they are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. This should be changed into: * This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens and Refresh Tokens. This cryptographically binds these tokens to the TLS connections over which they are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle attacks, but does not protect in case two clients agree to collaborate, since one client can compute the necessary information for the other client without the need to release his key(s) to the other client.* ** ** Denis --------------9E3D0D6DEF50FB8617116055 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
There has been a WGLC in the Token Binding (tokbind) WG about the following documents:

  draft-ietf-tokbind-protocol
  draft-ietf-tokbind-https
  draft-ietf-tokbind-negotiation

I have posted the following comments:

This set of documents failed to meet the terms of references of the WG charter.

It is not resistant to the ABC attack (Alice and Bob collusion attack).

In this attack Bob who is older than 18 colloborates with Alice and transmits a token to Alice
who is only 14 so that she can demonstrate to a RS that she is older than 18.

This kind of attack is not even mentionned in the security considerations section.


========================================================================

There are two options:
 
 Option A: drop this series of documents, i.e. :

  draft-ietf-tokbind-protocol
  draft-ietf-tokbind-https
  draft-ietf-tokbind-negotiation

or

Option B: clearly mention that the ABC attack cannot be countered using TLS binding.

In case, the latter decision would be taken by the tokbind WG, I have proposed a few text replacements.

1 - In draft-ietf-tokbind-protocol, change the abstract in the following way
(and modify the content of the document in accordance): 

   This document specifies Version 1.0 of the Token Binding protocol.
   The Token Binding protocol allows client/server applications to
   create long-lived, uniquely identifiable TLS [RFC5246] bindings
   spanning multiple TLS sessions and connections.  Applications are
   then enabled to cryptographically bind security tokens to the TLS
   layer.  However, the binding a security token to a TLS connection
   is unable to counter collaboration attacks between two clients
   since one client can compute the necessary information for the
   other client without the need to release his key(s) to the other
   client.  For an effective protection against collaboration attacks,
   an appropriate format of the security token, together with an
   appropriate validation of some fields of it, must be used.  To
   protect privacy, the Token Binding identifiers are only transmitted
   encrypted and can be reset by the user at any time.

Also the introduction states:

   (...)   

   In order to successfully export and replay a bound security token,
   the attacker needs to also be able to export the client's private
   key, which is hard to do in the case of the key generated in a secure
   hardware module. Proposed replacement

This should be replaced with:

 (...)

   In order to successfully export and replay a bound security token,
    a client does not need to export the client's private key, since
   it can perform all the necessary computations in the case of a
   collaboration attack.

2 - In draft-ietf-tokbind-https add two additional paragraphs in the abstract
(and modify the content of the document in accordance):

Abstract
    
   This document describes a collection of mechanisms that allow HTTP
   servers to cryptographically bind authentication tokens (such as
   cookies and OAuth tokens) to TLS [RFC5246] connections.

   We describe both _first-party_ and _federated_ scenarios.  In a
   first-party scenario, an HTTP server is able to cryptographically
   bind the security tokens it issues to a client, and which the client
   subsequently returns to the server, to the TLS connection between the
   client and server.  Such bound security tokens are protected from
   misuse since the server can generally detect if they are replayed
   inappropriately, e.g., over other TLS connections. 

   However, the binding a security token to a TLS connection is
   unable to counter collaboration attacks between two clients since
   one client can compute the necessary information for the other
   client without the need to release his key(s) to the other client.

   For an effective protection against collaboration attacks, an
   appropriate format of the security token, together with an
    appropriate validation of some fields of it, must be used. 

   Federated token bindings, on the other hand, allow servers to
   cryptographically bind security tokens to a TLS connection that the
   client has with a _different_ server than the one issuing the token.

   This Internet-Draft is a companion document to The Token Binding 
   Protocol [I-D.ietf-tokbind-protocol]

In section 7.1, change the text in the following way:

7.1. Security Token Export and Replay

   The goal of the Federated Token Binding mechanisms is to prevent
   attackers from exporting and replaying tokens used in protocols
   between the client and Token Consumer, thereby impersonating
   legitimate users and gaining access to protected resources.  Bound
   tokens can still be replayed by malware present in the client.
   They can also be exported and re-used when a client collaborates
   with another client.  In order to export the token to another
   machine and successfully use it, a client may export the 
   corresponding private key to the other client or may perform all 
   the necessary computations for the other client without exporting 
   the corresponding private.  Protecting the Token Binding private 
   key, e.g. in a hardware security module that prevents key export is 
   a good practice, but in such a case, it is inefficient to counter 
   the clients collaboration attack.

3 - draft-ietf-oauth-token-binding-01 is based on the same foundations and hence is suject to the ABC attack.

The same kind of decision is facing the OAuth WG:
Option A: drop draft-ietf-oauth-token-binding.
 
or

Option B: clearly mention that the ABC attack cannot be countered using TLS binding.

In case, the latter decision would be taken by the OAuth WG, the abstract should be changed
(and the content of the document should be modified in accordance).

The current abstract states:

   This specification enables OAuth 2.0 implementations to apply Token
   Binding to Access Tokens and Refresh Tokens.  This cryptographically
   binds these tokens to the TLS connections over which they are
   intended to be used.  This use of Token Binding protects these tokens
   from man-in-the-middle and token export and replay attacks.

This should be changed into:

   This specification enables OAuth 2.0 implementations to apply Token
   Binding to Access Tokens and Refresh Tokens.  This cryptographically
   binds these tokens to the TLS connections over which they are
   intended to be used.  This use of Token Binding protects these tokens
   from man-in-the-middle attacks, but does not protect in case two 
   clients agree to collaborate, since one client can compute the 
   necessary information for the other client without the need to 
   release his key(s) to the other client.
 

Denis
--------------9E3D0D6DEF50FB8617116055-- From nobody Wed Dec 21 11:17:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4B1295A0 for ; Wed, 21 Dec 2016 11:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEcWgCxphnbA for ; Wed, 21 Dec 2016 11:17:41 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 2C073127735 for ; Wed, 21 Dec 2016 11:17:41 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id A29227803A2 for ; Wed, 21 Dec 2016 20:17:38 +0100 (CET) To: oauth@ietf.org References: <97ba9e08-6179-3157-1017-c616c42ba64f@free.fr> From: Denis Message-ID: <2e7651a5-1586-d72d-c913-57ca48061303@free.fr> Date: Wed, 21 Dec 2016 20:17:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <97ba9e08-6179-3157-1017-c616c42ba64f@free.fr> Content-Type: multipart/alternative; boundary="------------E7D165A549FE061BF92D6DA7" Archived-At: Subject: [OAUTH-WG] Comments on draft-ietf-oauth-pop-architecture-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 19:17:45 -0000 This is a multi-part message in MIME format. --------------E7D165A549FE061BF92D6DA7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Comments on draft-ietf-oauth-pop-architecture-08 : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture This document identifies the four following threats in Section 4: * Token manufacture/modification, * Token disclosure, * Token redirect, and * Token reuse. However, this section is omitting to consider the ABC attack (Alice and Bob collusion attack). In this attack Bob who is older than 18 collaborates with Alice and transmits an access token to Alice who is only 14 so that she can demonstrate to a resource server that she is older than 18. Since the remaining of the document is only considering the threats mentioned in Section 4, it does not mandate any requirement to counter the ABC attack nor suggests a means to counter it. In section 5, various requirements are considered. On page 9, under the wording "Collusion", there are the following explanations *Resource servers that collude can be prevented from using information related to the resource owner to track the individual. * *That is, two different resource servers can be prevented from determining that the same resource owner has authenticated to both of them.Authorization servers MUST bind different keying material to access tokens used for resource servers from different origins (or similar concepts in the app world).* Two cases should be considered instead: (a) *Server Collusions*, where the current text may fit, and (b) *Client Collusions*. Client Collusions might be defined in the following way:** *Clients Collusion* ** *Clients may collude, i.e. a client can obtain a token and pass it to another client that can then use it for its own benefits. As an example, in a scenario described as ABC attack (Alice and Bob collusion attack), Bob who is older than 18 collaborates with Alice and transmits an access token to Alice who is only 14 so that she can demonstrate to a server that she is older than 18. The protection of binding keys in an hardware security module is a first step to counter such a scenario, but is insufficient by itself since the Bob can still perform all the computations that Alice needs and transmit the results to her.* ** *Clients collusion can however be prevented if such an hardware security module (or secure element) protects the keys but also supports additional security properties.* ** In section 5, Channel Binding is being considered with the following explanations: *A solution MUST enable support for channel bindings.The concept* *of channel binding, as defined in [RFC5056], allows applications* *to establish that the two end-points of a secure channel at one* *network layer are the same as at a higher layer by binding* *authentication at the higher layer to the channel at the lower* *layer.* As explained in other emails, channel binding is efficient to counter man-in-the-middle attacks but is inefficient to counter the ABC attack. Hence the use of the word "MUST" is not appropriate. The first sentence should be removed. The paragraph should be changed into : *Channel Binding* *The concept of channel binding, as defined in [RFC5056], allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. While efficient to counter man-in-the-middle attacks, channel binding is unable to counter clients collusions.* ** At the end of section 6.3. (Key Confirmation), a paragraph should be added. ** *Whatever kind of cryptography is being used, such methods when used in isolation are unable to counter collusions between clients.* ** The last sentence of section 6.4 states: ** *In all cases above it has to be ensured that the client is able to* *keep the credentials secret.* ** After that sentence, the following sentence should be added: ** *However, when two clients agree to collaborate, these approaches, used alone, are unable to counter clients collusions.* ** Section 8 states: ** *8.Security Considerations* ** *The purpose of this document is to provide use cases, requirements,* *and motivation for developing an OAuth security solution extending* *Bearer Tokens.As such, this document is only about security.* ** This should be replaced by: ** *8.Security Considerations* ** *This document considers various threats. In the case where two users agree to collaborate, a client can obtain an access token and pass it to another client which can then use it for its own benefits. This document does not specify in details the means to counter such a threat. * * The use of secure elements or of ***hardware security modules* protecting the private keys or/and the secret keys used by a given client would be ***one way to counter *that threat but additional security properties would also need to be supported by such **secure elements or ***hardware security modules*****. * * * ** There are two options for this WG: *Option A*: incorporate the proposed additions and hence implicitly recognize that the ABC attack is not countered by this architecture. or ** *Option B*: attempt to propose solutions to counter the ABC attack and hence continue to work on this document This implies working on a rather different PoP Architecture. There exists different solutions. 1) One of them mandates the deployment of secure elements, but the architecture is very complex and requires up to 45 exchanges most of them using secure messaging (See EN 419212-2 : Application Interface for smart cards used as Secure Signature Creation Devices). Privacy has not been considered when the architecture has been built and hence this solution is not privacy friendly. In particular, Resource Servers are able to correlate their user accounts. Resource Servers are also required to use hardware security modules. 2) Another one does not mandate the use of a secure element (or of an hardware security module). Resource Servers are unable to correlate their user accounts which is a nice privacy property, ... but most of the time receive a set of attributes that is sufficient to fully identify the user ! (this could be changed, but it is how the current architecture has been deployed). The currently deployed solution mandates the use of a single Authorization Server that knows where each access token it generates will be used. In addition, the Authorization Server knows all the identity attributes of each user and is able to track the accesses of each user. Hence, this single Authorization Server (managed by a government) would have (or has ?) the perfect position to act as Big Brother. 3) Another one has been built from the very beginning with privacy in mind and hence has been using a "Privacy by Design" approach and, during its construction, the ABC attack has been specifically considered. It mandates the use of secure elements (or of hardware security modules) with specific properties and mandates the use of protocols with specific characteristics both between clients and Authorization Servers and between clients and Resource Servers. Authorization Servers and Resource Servers are NOT required to use any hardware security module. One of the side benefits of this solution is that Authorization Servers are unable to know where the access tokens they generate for a given client will be used. Hence their ability to act as Big Brother is limited. 4) Other solutions may exist. ** Since the ABC attack is about to cheat that a person is older than 18, privacy considerations are of utmost importance. The current document has a "Security Considerations" section but is lacking a "Privacy Considerations" section. Both are of equal importance. Denis ** --------------E7D165A549FE061BF92D6DA7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Comments on draft-ietf-oauth-pop-architecture-08 : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture

This document identifies the four following threats in Section 4:

  • Token manufacture/modification,
  • Token disclosure,
  • Token redirect, and
  • Token reuse.

However, this section is omitting to consider the ABC attack (Alice and Bob collusion attack).
In this attack Bob who is older than 18 collaborates with Alice and transmits an access token to Alice
who is only 14 so that she can demonstrate to a resource server that she is older than 18.

Since the remaining of the document is only considering the threats mentioned in Section 4, it does not mandate
any requirement to counter the ABC attack nor suggests a means to counter it.

In section 5, various requirements are considered. On page 9, under the wording "Collusion",
there are the following explanations

 

      Resource servers that collude can be prevented from using
      information related to the resource owner to track the individual.

      That is, two different resource servers can be prevented from
      determining that the same resource owner has authenticated to both
      of them.  Authorization servers MUST bind different keying
      material to access tokens used for resource servers from different
      origins (or similar concepts in the app world).

Two cases should be considered instead: (a) Server Collusions, where the current text may fit, and (b) Client Collusions.

Client Collusions might be defined in the following way:

Clients Collusion

 

      Clients may collude, i.e. a client can obtain a token and pass it
      to another client that can then use it for its own benefits. As
      an example, in a scenario described as ABC attack (Alice and Bob
      collusion attack), Bob who is older than 18 collaborates with
      Alice and transmits an access token to Alice who is only 14 so
      that she can demonstrate to a server that she is older than 18. 
      The protection of binding keys in an hardware security module is
      a first step to counter such a scenario, but is insufficient by
      itself since the Bob can still perform all the computations that
      Alice needs and transmit the results to her.

 

      Clients collusion can however be prevented if such an hardware
      security module (or secure element) protects the keys but also
      supports additional security properties.

 

In section 5, Channel Binding is being considered with the following explanations:

 

      A solution MUST enable support for channel bindings.  The concept

      of channel binding, as defined in [RFC5056], allows applications

      to establish that the two end-points of a secure channel at one

      network layer are the same as at a higher layer by binding

      authentication at the higher layer to the channel at the lower

      layer.

As explained in other emails, channel binding is efficient to counter man-in-the-middle attacks but is inefficient to counter
the ABC attack. Hence the use of the word "MUST" is not appropriate. The first sentence should be removed.
The paragraph should be changed into :

Channel Binding

 

      The concept of channel binding, as defined in [RFC5056], allows
      applications to establish that the two end-points of a secure
      channel at one network layer are the same as at a higher layer
      by binding authentication at the higher layer to the channel at
      the lower layer.  While efficient to counter man-in-the-middle
      attacks, channel binding is unable to counter clients collusions.

 

At the end of section 6.3. (Key Confirmation), a paragraph should be added.

 

      Whatever kind of cryptography is being used, such methods when
      used in isolation are unable to counter collusions between clients.

 

The last sentence of section 6.4 states:

 

   In all cases above it has to be ensured that the client is able to

   keep the credentials secret.

 

After that sentence, the following sentence should be added:

 

    However, when two clients agree to collaborate, these approaches,
    used alone, are unable to counter clients collusions.

 

Section 8 states:

 

8.  Security Considerations

 

   The purpose of this document is to provide use cases, requirements,

   and motivation for developing an OAuth security solution extending

   Bearer Tokens.  As such, this document is only about security.

 

This should be replaced by:

 

8.  Security Considerations

 

   This document considers various threats. In the case where two users
   agree to collaborate, a client can obtain an access token and pass it
   to another client which can then use it for its own benefits. This
   document does not specify in details the means to counter such a threat.
  

   The use of secure elements or of hardware security modules protecting
   the private keys or/and the secret keys used by a given client would
   be one way to counter that threat but additional security properties
   would also need to be supported by such secure elements or hardware
   security modules.



There are two options for this WG:
 
 Option A: incorporate the proposed additions and hence implicitly recognize that the ABC attack is not countered
by this architecture.

or

Option B: attempt to propose solutions to counter the ABC attack and hence continue to work on this document
This implies working on a rather different PoP Architecture.

There exists different solutions.

1) One of them mandates the deployment of secure elements, but the architecture is very complex and requires
up to 45 exchanges most of them using secure messaging (See EN 419212-2 : Application Interface for smart cards
used as Secure Signature Creation Devices). Privacy has not been considered when the architecture has been built
and hence this solution is not privacy friendly. In particular, Resource Servers are able to correlate their user accounts.
Resource Servers are also required to use hardware security modules.


2) Another one does not mandate the use of a secure element (or of an hardware security module). Resource Servers are
unable to correlate their user accounts which is a nice privacy property, ... but most of the time receive a set of attributes
that is sufficient to fully identify the user ! (this could be changed, but it is how the current architecture has been deployed).
The currently deployed solution mandates the use of a single Authorization Server that knows where each access token
it generates will be used. In addition, the Authorization Server knows all the identity attributes of each user and is able to track
the accesses of each user. Hence, this single Authorization Server (managed by a government) would have (or has ?) the
perfect position to act as Big Brother.


3) Another one has been built from the very beginning with privacy in mind and hence has been using a "Privacy by Design"
approach and, during its construction, the ABC attack has been specifically considered. It mandates the use of secure elements
(or of hardware security modules) with specific properties and mandates the use of protocols with specific characteristics
both between clients and Authorization Servers and between clients and Resource Servers. Authorization Servers and Resource
Servers are NOT required to use any hardware security module.

One of the side benefits of this solution is that Authorization Servers are unable to know where the access tokens they generate
for a given client will be used. Hence their ability to act as Big Brother is limited.


4) Other solutions may exist.



Since the ABC attack is about to cheat that a person is older than 18, privacy considerations are of utmost importance.
The current document has a "Security Considerations" section but is lacking a "Privacy Considerations" section.
Both are of equal importance.


Denis

 

--------------E7D165A549FE061BF92D6DA7-- From riyadh.biyram@gmail.com Thu Dec 22 03:49:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0877A129859 for ; Thu, 22 Dec 2016 03:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBiV-bUuG8PH for ; Thu, 22 Dec 2016 03:49:37 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD0B129856 for ; Thu, 22 Dec 2016 03:49:36 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id c47so232230902qtc.2 for ; Thu, 22 Dec 2016 03:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dOmEfp+gi4eAjYgWXXg+XyzKs/fVOLn7l7+I0eJv/+c=; b=cnHLVuPsTEzDBx8/MBpSWu2bhZ+EopPYrA8kQ/+dCr9qC0Wj9BQ9nftKWdHRE08DVl 4ilsSXKpVdxn1ITEQdSIZv8Efz6l/6/Y9BMl42XvcfgcASZCbOxytE2+NezwIycJy/KL 8n+K9LXbXqH5RyzPl26F4sKa69ZMSvmxR0Jzj7xTu9289KF+2jvYIauzfrnSzkXXl2da zkP6/ZdrzECVVqwL1CXIZ1BZSL+coIB1Y/5jFneofHDBZCty4ovi/lyLQbzJtHcMitkk EhMESilojk/cbMurqru49tzO+R5pHEmLwFYf4mU43qf58R/wnkT/43TnyckPpc/ebRqz SrtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dOmEfp+gi4eAjYgWXXg+XyzKs/fVOLn7l7+I0eJv/+c=; b=XpH/8H7WoqXyzjAD7tBbVI5/u1qW3sg46QGVZPqzK+wtejaRuPl+XasJWwgON4GbHj j3YThKt1JYnYnpZkTas15uAvyrVaZOxZEvc1wY4k19k/oOpsnwsPYNYsObbmblOJUjbt wNVwToV/d/SIV9kWOf9s7J4D22kX7eO/kKARs5LV6vfaD1eGWRZlO8Fk/mYotwR+nHkm K0VeqlysRVA4Bb1LwcA1MVwpVOqdW9PsMASPc7GBDyA/FRv8/y2CrLo34HnmSqcItkVn TM+JotbdywJHTiI7eXaX7a1LlCx2nophdLYMIPBWXHsW/JvROP7Oyl7IUYDL4u2nWlHA ibmQ== X-Gm-Message-State: AIkVDXKJaIF7ZujBFwp+XKq80jTgnh+SVQ82vK3JLxpV3yFvWi91vmOlsVgUt3bJvLf4km5QGjR+GbvIP65Hew== X-Received: by 10.200.38.177 with SMTP id 46mr9079498qto.107.1482407375913; Thu, 22 Dec 2016 03:49:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.233.235.130 with HTTP; Thu, 22 Dec 2016 03:49:35 -0800 (PST) From: Riyadh Biyram Date: Thu, 22 Dec 2016 12:49:35 +0100 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1149b9a80dc79605443dddf1 Archived-At: X-Mailman-Approved-At: Tue, 27 Dec 2016 06:44:04 -0800 Subject: [OAUTH-WG] Downloading and uploading files by using OAuth in C# language on the Dropbox Platform without creating a new app on the Dropbox Platform to get applicationkey and secretkey? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 22:38:03 -0000 --001a1149b9a80dc79605443dddf1 Content-Type: text/plain; charset=UTF-8 Hello, I use currently the OAuth technique and I have a question and I hope, you can help me? I would like to know how can I use OAuth 2.0 (within C# WPF application or any langauge to achieve the request) to download and upload files from Dropbox. It appears that the OAuth 2.0 works by forwarding you to a Dropbox Platform and getting you confirm details for example that is means registering the application with external providers(Dropbox Platform API) to get the application key and secret key. (creating a new application on the Dropbox platform to get applicationkey and secret key https://www.dropbox.com/developers/apps/create). How can I use it without application key and secret key direct to connect and maybe get the application key with secret key in background without showing anything to the user of the application for example like "Screenpresso" software with this software you don't need to get applciation key or secret key only you sign in by the email and password to grant access the features. If there are other extra techniques, please write them to my email. Thanks in advance. Best regards, Riyadh Biyram *Riyadh Biyram* Software Engineer & Software Developer m: + <555-77777>49 (0) 1577 858 6688 | e:rb50575@gmail.com Skype :riyadh.biyram --001a1149b9a80dc79605443dddf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Hello,

I use currently the OA=
uth technique and I have a question and I hope, you can help me?

I would like to know how can I use OAuth 2.=
0 (within C# WPF application or any langauge to achieve the request) to dow=
nload and upload files from Dropbox. It appears that the OAuth 2.0 works by=
 forwarding you to a Dropbox Platform and getting you confirm details for e=
xample that is means registering the application with external providers(Dr=
opbox Platform API) to get the application key and secret key.
(creating a new application on =
the Dropbox platform 
to get applicationkey and secret key
 https://www.dropbox.com/developers/apps/create).

How can I use it without application key and sec=
ret key direct to connect and maybe get the application key with secret key=
 in background without showing anything to the user of the application for =
example like "Screenpresso" software with this software you don&#=
39;t need to get applciation key or secret key only you sign in by the emai=
l and password to grant access the features.
 
If there are othe=
r extra techniques, please write them to my email.

Thanks in advance.
Best regards,<=
/span>

Riyadh Biyram
=

--001a1149b9a80dc79605443dddf1-- From nobody Tue Dec 27 09:52:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF279129670 for ; Tue, 27 Dec 2016 09:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV8Trx24z8Cd for ; Tue, 27 Dec 2016 09:52:40 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316AD12950F for ; Tue, 27 Dec 2016 09:52:40 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id g1so107842113pgn.0 for ; Tue, 27 Dec 2016 09:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8+Um9wt/x6c24UPMJQMb/elUHiDQIdNiaEwuaXitQNw=; b=jIEWf1Zhq06fLdKgRkIDSrxak3xQJutY2QWSFimRqH1qoRfH2iBxQTaSymgRvXsOti LKPfuszKfA842lJMnrWpJ3/G/6ZGoXbuFR7ueE4FyAAIlCiuC4jOcgtxC537+qpP1KLs oFh4Jw4dlhM7pwuIA10V+HEznGHcnDb6EjbP5LGc63jvGG/nY2bMI445thZWcNUIy0Lu DBl6Z9qijRKXon0FnxInJudXm30AkcsoaCiWLY57FPtzrIMPboUJBc1/gF5vk65KL0mY yFZM/NCyZwaynkBcJ2s+mBV1yuEDzAvybAfhYRaAW6cRzNsVnzySJRtLd1ul+2jFdLbv wTzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8+Um9wt/x6c24UPMJQMb/elUHiDQIdNiaEwuaXitQNw=; b=T8P+YhUGojgjfCtfYo0gShipmUUaau+ZuE9v6Y50WdrB5Fg44HcQA8nJv+Io5nnndm 6uhr8MKSmH3My9C/2BhXcJbPFR5dg7OepIWkYu3OgAWBbWkkFuu9jue+1Sv7Lteiy96G FH9kNVpTlFFpp3d+dkqo8eVitP2a1wC0JU19J3t9OkRP+Qvt7/DUw3LZqNOz7J9soOUl fEhHLzvvx3Fp1RkTvcLf6Zq3rpRzMjLE5X+CaPej7GA9/0ajUO9DWBTRlgJdUqW/Sacw BsvFa0u+TL5uYn6sW7/8d/lgHBv4bU6KCG4WEw1KQvB6jvrmoAVoyGPRmPcSE9YJCYSk U0QA== X-Gm-Message-State: AIkVDXJ0aYq6WRO5IyBnOru8Kn7Yrx4eCLoVP+IRHbvnh3VKLQ56tDnHI6fhl7aIarMbgj47 X-Received: by 10.84.133.129 with SMTP id f1mr67959283plf.64.1482861159556; Tue, 27 Dec 2016 09:52:39 -0800 (PST) Received: from [10.108.31.69] (mobile-166-171-120-021.mycingular.net. [166.171.120.21]) by smtp.gmail.com with ESMTPSA id j68sm91041649pfk.95.2016.12.27.09.52.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 09:52:38 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-4B09806A-F63A-4ABD-93F8-5B488EE1835B Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Tue, 27 Dec 2016 07:52:37 -1000 Content-Transfer-Encoding: 7bit Message-Id: <0623184E-6E50-4301-8499-3F2459E3E377@manicode.com> References: To: Riyadh Biyram Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Downloading and uploading files by using OAuth in C# language on the Dropbox Platform without creating a new app on the Dropbox Platform to get applicationkey and secretkey? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 17:52:42 -0000 --Apple-Mail-4B09806A-F63A-4ABD-93F8-5B488EE1835B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Riyadh, You best off reading the Dropbox OAuth guide and asking Dropbox support with= your questions. Each provider does OAuth a little bit differently. https://www.dropbox.com/developers/reference/oauth-guide Respectfully, -- Jim Manico @Manicode > On Dec 22, 2016, at 1:49 AM, Riyadh Biyram wrote= : >=20 >=20 > Hello, >=20 > I use currently the OAuth technique and I have a question and I hope, you c= an help me? >=20 > I would like to know how can I use OAuth 2.0 (within C# WPF application or= any langauge to achieve the request) to download and upload files from Drop= box. It appears that the OAuth 2.0 works by forwarding you to a Dropbox Plat= form and getting you confirm details for example that is means registering t= he application with external providers(Dropbox Platform API) to get the appl= ication key and secret key. > (creating a new application on the Dropbox platform=20 > to get applicationkey and secret key > https://www.dropbox.com/developers/apps/create). >=20 > How can I use it without application key and secret key direct to connect a= nd maybe get the application key with secret key in background without showi= ng anything to the user of the application for example like "Screenpresso" s= oftware with this software you don't need to get applciation key or secret k= ey only you sign in by the email and password to grant access the features. > =20 > If there are other extra techniques, please write them to my email. >=20 > Thanks in advance. > Best regards, >=20 > Riyadh Biyram >=20 > =09 > Riyadh Biyram > Software Engineer & Software Developer > m: +49 (0) 1577 858 6688 | e:rb50575@gmail.com Skype :riyadh.biyram=20= > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4B09806A-F63A-4ABD-93F8-5B488EE1835B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Riyadh,

You best off reading the Drop= box OAuth guide and asking Dropbox support with your questions. Each provide= r does OAuth a little bit differently.
<= br>

Respectfully,
<= div>--
Jim Manico
@Manicode

On Dec 2= 2, 2016, at 1:49 AM, Riyadh Biyram <riyadh.biyram@gmail.com> wrote:

m:= =C2=A0+49 (0) 1577 858 6688= =C2=A0 | =C2=A0 =C2=A0e:rb50575@gmail.= com=C2=A0Skype :riyadh.biyram=C2=A0
 
Hel=
lo,

I use currently the OAuth techniq=
ue and I have a question and I hope, you can help me?

I would like to know how can I use OAuth 2.0 (within C# WPF=
 application or any langauge to achieve the request) to download and upload f=
iles from Dropbox. It appears that the OAuth 2.0 works by forwarding you to a=
 Dropbox Platform and getting you confirm details for example that is means r=
egistering the application with external providers(Dropbox Platform API) to g=
et the application key and secret key.
(creating a new application on the Dropbox platform
= 
to get applicationkey and s=
ecret key
 https://www.dropbox.com/dev=
elopers/apps/create).

How can I u=
se it without application key and secret key direct to connect and maybe get=
 the application key with secret key in background without showing anything t=
o the user of the application for example like "Screenpresso" software with t=
his software you don't need to get applciation key or secret key only you si=
gn in by the email and password to grant access the features.
 
If there are other e=
xtra techniques, please write them to my email.

Thanks in advance.
Best regards,

Riyadh Biyram

Riyadh B= iyram
Software Engineer & Software Developer
m:  +49 (0) 1577 858 6688   |  =  e:rb50575@gmail.com Skype :riyadh.biyram 
=
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-4B09806A-F63A-4ABD-93F8-5B488EE1835B-- From nobody Tue Dec 27 16:57:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93118129450 for ; Tue, 27 Dec 2016 16:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cabhKyzbXJ4 for ; Tue, 27 Dec 2016 16:57:19 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B737D129432 for ; Tue, 27 Dec 2016 16:57:18 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id u144so72632923wmu.1 for ; Tue, 27 Dec 2016 16:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hzxZAzlZvp7295tTUI1CKgBJGTQIJmHFh3JpO45Lea4=; b=kr2rlysgRoNkIjkKFcd8zHqR7Ypmcv7/869/8qEISCvS2ytfGZwlSVs+sWck1Y5yi2 HaAWQvvn/qySBpJ3QwdxZ8p1FAteEO1rVSaopHhnuVVAaWdGToSu9A7mCJTOnUFihzgj iKTHZsUiSOPJJEloNNDo1tb9bhzjjUo2p8gdLpiaYp3LlRUdRq8vBVX9CgH1mHJYm+QR ejQ7QoAPY84n13ocUOK2Hpn2gA/evtCxRoFqC3JHGmf0doB8hd/xW9p5kIsrbptThoSs Jq8JdMUHfB73nFHe8rwX6j4rHVijIXYEv6KTpT/bTxR3NRpm9hrZuVYxqmIyahrCiRjR HyNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hzxZAzlZvp7295tTUI1CKgBJGTQIJmHFh3JpO45Lea4=; b=nZb62h4POwhP04Q7K06cKibBVEIaBsI8C7peYvhb2x8UIV3/6D/DasMRW3GHSi42j9 upiF7yMYK4GzrB/2P6cK0YSkgp1EC/D1U+Ty5ECGdOi+PXiFtdGqUsZil5ts8+KkzJWW k7n0cP6EgvVAvgFiYLOVcJY+BQaTF5G37VH6kpSEldcY+hNhLGVyZWyTIbyerVu0ClVG YMxTb0zVmtn3UTbpFH8bdP0efLhpJKd/f0suCKOAajbszTLPq8uGpfzU9TeJF62wnh42 iie2zM/U0WiPwtARxWhwRAY3cfz1wI54goQ6J8sZ7ceOynEbf0afLM8m3podO2poFm6J IYtg== X-Gm-Message-State: AIkVDXK8wktpS5wCoqZsfc3mws9n2rSM4fpEk7ZEqRnvlsyFuQV0tmmxlEuZdBOwO459fITYW7094NMJJcgQSw== X-Received: by 10.28.184.23 with SMTP id i23mr35320628wmf.66.1482886637171; Tue, 27 Dec 2016 16:57:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Wed, 28 Dec 2016 00:57:05 +0000 Message-ID: To: Kathleen Moriarty , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a114b771c403a5f0544ad738d Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 00:57:20 -0000 --001a114b771c403a5f0544ad738d Content-Type: text/plain; charset=UTF-8 Hi Sorry to have taken so long to respond -- too much travel. My responses inline. On Sat, Oct 29, 2016 at 12:39 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > I just reviewed draft-ietf-oauth-jwsreq, and it looks great and seems to > be a nice addition to help with security. Thanks for your work on it. > > I only have a few comments. > > The first is just about some wording that is awkward in the TLS section. > > What's there now: > > Client implementations supporting the Request Object URI method MUST > support TLS as recommended in Recommendations for Secure Use of > Transport Layer Security (TLS) and Datagram Transport Layer Security > (DTLS) [RFC7525]. > > How about: > > Client implementations supporting the Request Object URI method MUST > support TLS following Recommendations for Secure Use of > Transport Layer Security (TLS) and Datagram Transport Layer Security > (DTLS) [RFC7525]. > > Not a major change and just editorial, so take it or leave it. > Accepted as presented in my personal copy. See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0de915b22f13 > > 2. In section 10, the introduction sentence leaves me wondering where the > additional attacks against OAuth 2.0 should also have a pointer in this > sentence: > > In addition to the all the security considerations discussed in OAuth > 2.0 [RFC6819], the following security considerations should be taken > into account. > > > An IETF document about them has not been adopted yet. Shall I just add a sentence or two describing the threats that each sub-sections are dealing with? Or shall I point to the research papers that I was reading? (Some of them are not freely available though.) > 3. Nit: in first line of 10.4: > > Although this specification does not require them, researchs > > s/researchs/researchers/ > In fact, I meant either "research" or "researches" as I was not pointing to persons but rather the work done by them. I fixed it as "research" in my personal copy. See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0ec83d0c0c36 > 4. I'm sure you'll be asked about the following: > > ISO/IEC 29100 > [ISO29100] is a freely accessible International Standard and its > Privacy Principles are good to follow. > > What about the IETF privacy considerations for protocols, RFC6973, were > they also considered? I think you are covering what's needed, but no > mention of it and favoring an ISO standard seems odd., using both is fine. > Good point. ISO/IEC 29100 is a high level document so the coverage is wider but does not get into concrete details where as RFC6973 gives more concrete guidance. They complement each other. I have added a paragraph about RFC6873 in my personal copy. See: https://bitbucket.org/Nat/oauth-jwsreq/commits/9030e1be5cac > Thank you. > -- > > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation --001a114b771c403a5f0544ad738d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Sorry to have taken so long to respo= nd -- too much travel.=C2=A0

My responses inline.= =C2=A0

On Sat, Oct 29,= 2016 at 12:39 AM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hello,
I just reviewed draft-ietf-oauth-jwsreq, and it looks great and seems to= be a nice addition to help with security.=C2=A0 Thanks for your work on it= .

I only have a few comments.

The first is just about s= ome wording that is awkward in the TLS section.

What's there = now:
Client implementations supporting the Request Object URI method MUST
   support TLS as recommended in Recommendations for Secure Use of
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) [RFC7525].
How about:
Client implementations supporting the Request Object =
URI method MUST
   support TLS following Recommendations for Secure Use of
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) [RFC7525].
Not a major change= and just editorial, so take it or leave it.
=

Accepted as presented in my personal copy.=C2=A0
<= div>See:=C2=A0https://bitbucket.org/Nat/oauth-jwsreq/commits/0de915b22f13<= /div>
=C2=A0

2. In section 10, the intr= oduction sentence leaves me wondering where the additional attacks against = OAuth 2.0 should also have a pointer in this sentence:

   In addition to the all the security c=
onsiderations discussed in OAuth
   2.0 [RFC6819], the following security considerations should be taken
   into account.


An IETF document about= them has not been adopted yet. Shall I just add a sentence or two describi= ng the threats that each sub-sections are dealing with? Or shall I point to= the research papers that I was reading? (Some of them are not freely avail= able though.)=C2=A0
=C2=A0
3. Nit: in first line of 10.4:
Alt=
hough this specification does not require them, researchs
s/researchs/researchers/
<= div>
In fact, I meant either "research" or "re= searches" as I was not pointing to persons but rather the work done by= them.=C2=A0
I fixed it as "research" in my personal co= py.=C2=A0


4. I'm sure = you'll be asked about the following:
ISO/IEC 29100 [ISO29100] is a freely accessible International Standard and its Privacy Principles are good to follow.
What about the IETF privacy considerations for protocols, RFC6973, were = they also considered?=C2=A0 I think you are covering what's needed, but= no mention of it and favoring an ISO standard seems odd., using both is fi= ne.=C2=A0

Good point. ISO= /IEC 29100 is a high level document so the coverage is wider but does not g= et into concrete details where as RFC6973 gives more concrete guidance.=C2= =A0 They complement each other. I have added a paragraph about RFC6873 in m= y personal copy.=C2=A0



Thank you.
--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a114b771c403a5f0544ad738d-- From nobody Wed Dec 28 08:27:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4951312944A for ; Wed, 28 Dec 2016 08:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2W9Aacl5Is6 for ; Wed, 28 Dec 2016 08:27:09 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38801129407 for ; Wed, 28 Dec 2016 08:27:09 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id h201so109956294qke.1 for ; Wed, 28 Dec 2016 08:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J3E6xFD5VJWIPrhhb5STHYx0fKxunCyeHJ8EsUsdxJw=; b=QDUco7MdcMxnc5IldfMbIIIiKurQyd1pwuVBlDVWdaF7+EVWnUripAFYqm9tvdAucj cOKMTwnx6zw9OgcnooRMRr1bNpcjz5WwMmZKrd5v5EybDUtko+pbV0gW9/oiJx/YrR0m HEAN5Xt7oKOQMlUs8n6qmqCu3i3vBgxD38k7ta9AeAw98NmyNVh4svqo+dM/ArRnA6OE JKTsoypLlH7A5w2qiTAfA/kkPVxV+4PTxvCrAeJaWsHdlpVKC6m579/Fzw1U6dzMxXTb 7A6fXs7sXDoGslIXX6lPM3OKi7rFASRH51FpGNTa7uw39CzEQrer9fJqMIv3pIJpF8J6 5Y1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J3E6xFD5VJWIPrhhb5STHYx0fKxunCyeHJ8EsUsdxJw=; b=OnWS8rwBwP0cGDw8g3kqt/FOLiCH63UdWbxkSgnzxngM79Rzs/azFBf7vym+uQSkp1 5LoMpx4SH3L7920P95eLEHx1cOSUr2TduYLijM7bstAAqDCUNYzGDg6rQbDZ68vlDy7K Kxqy+fo84gApB8IhE4HLVg8gfuBXEAYd4LCkjwCPbRX9F3/QeS7FB5MpJD67hJpFoAt3 LEECXX98b3fQob35F+UC7VHdZeezNPJ0PkmMwDzTc4LEWglaq3d76pdYY8sZeXJJtjk+ sJnjEf/ozAgzHd27F7GMPWmMo7NRwCsqk1UOLabRjNTWyvuY21jzIDbN0ZFf2O2rXRcl uO+w== X-Gm-Message-State: AIkVDXKffiz3Y9zncOD8+4SfeP3JbLAgLk3SgLMHV+irwve4sdUDdHlqSWgShE59kv5GV44QbMZiFFouis4eyA== X-Received: by 10.55.198.149 with SMTP id s21mr39656938qkl.196.1482942428405; Wed, 28 Dec 2016 08:27:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Wed, 28 Dec 2016 08:27:08 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Wed, 28 Dec 2016 11:27:08 -0500 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a11451488aae6580544ba7037 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 16:27:11 -0000 --001a11451488aae6580544ba7037 Content-Type: text/plain; charset=UTF-8 Hi Nat, Thank you for the updates. Please let me know when you publish a new version. I'll start last call after the new year. inline. On Tue, Dec 27, 2016 at 7:57 PM, Nat Sakimura wrote: > Hi > > Sorry to have taken so long to respond -- too much travel. > I hope you are able to rest a bit! > > My responses inline. > > On Sat, Oct 29, 2016 at 12:39 AM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hello, >> >> I just reviewed draft-ietf-oauth-jwsreq, and it looks great and seems to >> be a nice addition to help with security. Thanks for your work on it. >> >> I only have a few comments. >> >> The first is just about some wording that is awkward in the TLS section. >> >> What's there now: >> >> Client implementations supporting the Request Object URI method MUST >> support TLS as recommended in Recommendations for Secure Use of >> Transport Layer Security (TLS) and Datagram Transport Layer Security >> (DTLS) [RFC7525]. >> >> How about: >> >> Client implementations supporting the Request Object URI method MUST >> support TLS following Recommendations for Secure Use of >> Transport Layer Security (TLS) and Datagram Transport Layer Security >> (DTLS) [RFC7525]. >> >> Not a major change and just editorial, so take it or leave it. >> > > Accepted as presented in my personal copy. > See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0de915b22f13 > > >> >> 2. In section 10, the introduction sentence leaves me wondering where the >> additional attacks against OAuth 2.0 should also have a pointer in this >> sentence: >> >> In addition to the all the security considerations discussed in OAuth >> 2.0 [RFC6819], the following security considerations should be taken >> into account. >> >> >> > An IETF document about them has not been adopted yet. Shall I just add a > sentence or two describing the threats that each sub-sections are dealing > with? Or shall I point to the research papers that I was reading? (Some of > them are not freely available though.) > Any document that describes them will likely be an 'updates' to the OAuth spec, so we should be okay. Is the WG likely to adopt a draft soon? If so, we could wait to start IETF last call. > >> 3. Nit: in first line of 10.4: >> >> Although this specification does not require them, researchs >> >> s/researchs/researchers/ >> > > In fact, I meant either "research" or "researches" as I was not pointing > to persons but rather the work done by them. > I fixed it as "research" in my personal copy. > See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0ec83d0c0c36 > > >> 4. I'm sure you'll be asked about the following: >> >> ISO/IEC 29100 >> [ISO29100] is a freely accessible International Standard and its >> Privacy Principles are good to follow. >> >> What about the IETF privacy considerations for protocols, RFC6973, were >> they also considered? I think you are covering what's needed, but no >> mention of it and favoring an ISO standard seems odd., using both is fine. >> > > Good point. ISO/IEC 29100 is a high level document so the coverage is > wider but does not get into concrete details where as RFC6973 gives more > concrete guidance. They complement each other. I have added a paragraph > about RFC6873 in my personal copy. > > See: https://bitbucket.org/Nat/oauth-jwsreq/commits/9030e1be5cac > > I think you've covered the important privacy considerations from 6973, so the statement added on it should make that clear so the reader knows you've done the work for them already. Please let me know when the update has been posted. Thank you, Kathleen > >> Thank you. >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > -- Best regards, Kathleen --001a11451488aae6580544ba7037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nat,

Thank you for the updates.=C2= =A0 Please let me know when you publish a new version.=C2=A0 I'll start= last call after the new year. =C2=A0inline.

On Tue, Dec 27, 2016 at 7:57 PM, Nat Sakim= ura <sakimura@gmail.com> wrote:
Hi

Sorry to have taken so long t= o respond -- too much travel.=C2=A0

=
I hope you are able to rest a bit!
=C2=A0

My responses inline.= =C2=A0

On Sat, Oct 29, 2016 at 12:39 AM Kathleen Moriarty <kathleen.moriarty.ietf@= gmail.com> wrote:
Hello,

=
I just reviewed draft-i= etf-oauth-jwsreq, and it looks great and seems to be a nice addition to hel= p with security.=C2=A0 Thanks for your work on it.

I only have a few comments= .

= The first is just about some wording that is awkward in the TLS section.

What= 's there now:
Client implemen=
tations supporting the Request Object URI method MUST
   support TLS as recommended in Recommendations for Secure Use of
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) [RFC7525].
How about:
Client implementations supporting the Reques=
t Object URI method MUST
   support TLS following Recommendations for Secure Use of
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) [RFC7525].
Not a major change and just editorial, so take it or leave it.

Accepted as presented in my= personal copy.=C2=A0
=C2=A0

2. In section 10, the introduction sentence leaves me wondering where the= additional attacks against OAuth 2.0 should also have a pointer in this se= ntence:

   =
In addition to the all the security considerations discussed in OAuth
   2.0 [RFC6819], the following security considerations should be taken
   into account.
<= br class=3D"m_8335990636737575047gmail_msg">
=

An IETF document about them has not been adopted= yet. Shall I just add a sentence or two describing the threats that each s= ub-sections are dealing with? Or shall I point to the research papers that = I was reading? (Some of them are not freely available though.)=C2=A0
<= /div>

Any document that describes the= m will likely be an 'updates' to the OAuth spec, so we should be ok= ay.=C2=A0 Is the WG likely to adopt a draft soon?=C2=A0 If so, we could wai= t to start IETF last call.

=C2=A0=
3. Nit: in first line of 10.4:
Although this specification does not require them, researchs
s/researchs/research= ers/

In fact, I me= ant either "research" or "researches" as I was not poin= ting to persons but rather the work done by them.=C2=A0
I fixed i= t as "research" in my personal copy.=C2=A0
See:=C2=A0https://bitbucket.org/Nat/oauth-jwsreq/commits/0ec83= d0c0c36


4. I'm sure you'll be asked about the = following:
   ISO/IEC 29100
   [ISO29100] is a freely accessible International Standard and its
   Privacy Principles are good to follow.
What about the IETF privacy considerations for prot= ocols, RFC6973, were they also considered?=C2=A0 I think you are covering w= hat's needed, but no mention of it and favoring an ISO standard seems o= dd., using both is fine.=C2=A0

Good point. ISO/IEC 29100 is a high level document so the cove= rage is wider but does not get into concrete details where as RFC6973 gives= more concrete guidance.=C2=A0 They complement each other. I have added a p= aragraph about RFC6873 in my personal copy.=C2=A0


<= br>
I think you've covered the important privacy consideratio= ns from 6973, so the statement added on it should make that clear so the re= ader knows you've done the work for them already.

<= div>Please let me know when the update has been posted.

Thank you,
Kathleen=C2=A0

Thank you.
--

Best = regards,
Kathleen
<= /div>
 _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation




--

Best regards,
Kathleen
--001a11451488aae6580544ba7037--