email On Tue, Nov 20, 2018, 1:37 PM <oauth-requ...@ietf.org wrote:
> Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: OAuth Security Topics -- Recommend authorization code > instead of implicit (John Bradley) > 2. I-D Action: draft-ietf-oauth-security-topics-10.txt > (internet-dra...@ietf.org) > 3. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt > (Torsten Lodderstedt) > 4. Re: Token Binding & implicit (Torsten Lodderstedt) > > > > ---------- Forwarded message ---------- > From: John Bradley <ve7...@ve7jtb.com> > To: oauth@ietf.org > Cc: > Bcc: > Date: Tue, 20 Nov 2018 12:47:22 -0300 > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > > Yes the at_hash protects the client from accepting an injected AT. > > Unfortunately it doesn't do anything to protect against leakage in logs or > redirects. > > So without the AT using some sort of POP mechanism it is hard to say > sending it in a redirect is a good security practice. > > John B. > On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote: > > Hi Mike, > > I agree that OIDC hybrid flows offer additional security over the OAuth > implicit grant and are used in the wild. On my slides and in the initial > version of the new section, we had included the hybrid OIDC flows because of > their known token injection countermeasures. > > I nevertheless feel very uncomfortable to recommend those flows and any flow > issuing access tokens in the front channel. In the course of the detailed > review of the new text we realized two issues: > > 1) Since the access token is exposed in the URL, such flows possess a > significantly higher risk to leak the access token (e.g. through browser > history, open redirection and even referrer headers) than the code grant. > 2) There is no viable way to sender constrain access tokens issued in the > front channel. Given the WG decided to recommend use of sender constraint > tokens > (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), > it seems contradictory to recommend response types not supporting such an > approach. > > kind regards, > Torsten. > > > Am 19.11.2018 um 23:13 schrieb Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org> > <Michael.Jones=40microsoft....@dmarc.ietf.org>: > > This description of the situation is an oversimplification. OpenID Connect > secures the implicit flow against token injection attacks by including the > at_hash (access token hash) in the ID Token, enabling the client to validate > that the access token was created by the issuer in the ID Token (which is > also the OAuth Issuer, as described in RFC 8414). (Note that this mitigation > was described in draft-ietf-oauth-mix-up-mitigation.) > > Given the prevalence of this known-good solution for securing the implicit > flow, I would request that the draft be updated to describe this mitigation. > At the same time, I’m fine with the draft recommending the code flow over the > implicit flow when this mitigation is not used. > > Thank you, > -- Mike > > From: OAuth <oauth-boun...@ietf.org> <oauth-boun...@ietf.org> On Behalf Of > Hannes Tschofenig > Sent: Monday, November 19, 2018 2:34 AM > To: oauth <oauth@ietf.org> <oauth@ietf.org> > Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code > instead of implicit > > Hi all, > > The authors of the OAuth Security Topics draft came to the conclusion that it > is not possible to adequately secure the implicit flow against token > injection since potential solutions like token binding or JARM are in an > early stage of adoption. For this reason, and since CORS allows browser-based > apps to send requests to the token endpoint, Torsten suggested to use the > authorization code instead of the implicit grant in call cases in his > presentation > (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01). > > A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. > > Please provide a response by December 3rd. > > Ciao > Hannes & Rifaat > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > ---------- Forwarded message ---------- > From: internet-dra...@ietf.org > To: <i-d-annou...@ietf.org> > Cc: oauth@ietf.org > Bcc: > Date: Tue, 20 Nov 2018 11:26:58 -0800 > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-10.txt > Pages : 38 > Date : 2018-11-20 > > Abstract: > This document describes best current security practice for OAuth 2.0. > It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and covers new threats relevant due to the broader > application of OAuth 2.0. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > > > ---------- Forwarded message ---------- > From: Torsten Lodderstedt <tors...@lodderstedt.net> > To: oauth <oauth@ietf.org> > Cc: > Bcc: > Date: Tue, 20 Nov 2018 20:32:50 +0100 > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt > Hi all, > > the new revision contains the following changes: > > * added section on refresh tokens > * additional justifications for recommendation for code > * refactored 2.1 in order to distinguish CSRF, authz response replay and > mix-up (based on feedback by Joseph Heenan) > * added requirement to authenticate clients during code exchange (PKCE or > client credential) to 2.1.1. > * changed occurrences of SHALL to MUST > > As always: looking forward for your feedback. > > kind regards, > Torsten. > > > Am 20.11.2018 um 20:26 schrieb internet-dra...@ietf.org: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol WG of the > IETF. > > > > Title : OAuth 2.0 Security Best Current Practice > > Authors : Torsten Lodderstedt > > John Bradley > > Andrey Labunets > > Daniel Fett > > Filename : draft-ietf-oauth-security-topics-10.txt > > Pages : 38 > > Date : 2018-11-20 > > > > Abstract: > > This document describes best current security practice for OAuth 2.0. > > It updates and extends the OAuth 2.0 Security Threat Model to > > incorporate practical experiences gathered since OAuth 2.0 was > > published and covers new threats relevant due to the broader > > application of OAuth 2.0. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10 > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > ---------- Forwarded message ---------- > From: Torsten Lodderstedt <tors...@lodderstedt.net> > To: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> > Cc: oauth <oauth@ietf.org> > Bcc: > Date: Tue, 20 Nov 2018 20:36:39 +0100 > Subject: Re: [OAUTH-WG] Token Binding & implicit > I opt for (4) - Remove support/description of binding of access tokens > issued from the authorization endpoint > > I think the potential solution we worked out (slide 6) is to complex and > the security implications of the redirect via the resource servers are > still unclear. > > > Am 18.11.2018 um 13:32 schrieb Brian Campbell <bcampbell= > 40pingidentity....@dmarc.ietf.org>: > > > > During the first OAuth session in Bangkok the question "what to do about > token binding & implicit?" was raised. There was some discussion but > session time was limited and we had to move on before any real consensus > was reached. > > > > So I thought I'd bring the question to the WG list to generate some more > discussion on the issue. It's also related, at least in part, to a couple > of the other ongoing threads on the list about browser based apps and > security practices. > > > > The slides from the session are linked below. Slides 5 & 6 try and > explain the awkwardness of doing Token Binding with implicit. While slide 7 > lays out some (not very good) options for how to proceed. > > > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00 > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited... > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you._______________________________________________ > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
