Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt
Hi Joseph, > Am 09.11.2018 um 18:27 schrieb Joseph Heenan : > > Hi Torsten, > > A few comments having just read this afresh: > > 2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given > it appears to be permitted? SHALL is equivalent to MUST, changed it into SHOULD for the reason you gave. I also changed other occurrences of SHALL to MUST as it seems people are more familiar with this term. > > I find it a little hard to understand exactly what "avoid any redirects or > forwards which can be parameterized by URI query parameters” means > (particularly as it comes directly after a paragraph on the redirect_uri and > I initially thought it was talking about that. Perhaps something along the > lines of “avoid forwarding the user’s browser to a value from a uri query > parameter” might be clearer. Incorporated your text. > > " Clients SHALL ensure to only process “ could just be written ‘Client SHALL > only process” I think. That’s indeed simpler :-) > > > 2.1.1: > > "Authorization servers SHALL consider the” - is ’SHALL consider’ different > to ’SHOULD’? Or does it mean something like “SHALL implement at least one > countermeasure from <…>”. That wouldn't work since the text in RFC6819 gives implementors multiple mostly complementary measures. But the direction of your proposal makes sense, so I added the requirement for the AS to bind every code to a client (already stated in RFC6749) and to authenticate the client. Thanks to Dynamic Registration and PKCE this is now feasible and it seems to be the most effective mitigation to me. I also made the reference to RFC 6819 a SHOULD. > > 3.2.4: > > This says "Authorization codes SHOULD be invalidated by the AS after their > first use at the token endpoint”. > > https://tools.ietf.org/html/rfc6749#section-10.5 says: > > "Authorization codes MUST be short lived and single-use.”. > Thanks for pointing this out! > Does this "MUST be single-use” not effectively already require the code is > invalidated after first use? If so why downgrade this to a “SHOULD”? You are right. My feeling is single use can turn out to be a really hard to implement requirement. That’s why I would like to relax it. Given we now have a stronger requirement on client authentication that should be fine. Question to the list: what is your implementation experience regarding one time use authorization codes? Thanks for your feedback! kind regards, Torsten. > > > Cheers, > > Joseph > > >> On 9 Nov 2018, at 09:42, Torsten Lodderstedt wrote: >> >> Hi all, >> >> the new revision incorporates the recommendation to use more secure grant >> types instead of implicit we agreed to add during the WG session on Monday. >> It also has more text around justifications for our recommendation. >> Especially, there is a new section 3.6 on access token injection. >> >> I also posted about this topic on LinkedIn >> (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-grant-torsten-lodderstedt/) >> and Medium >> (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926) >> >> kind regards, >> Torsten. >> >>> Am 09.11.2018 um 09:32 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-09.txt >>> Pages : 35 >>> Date: 2018-11-09 >>> >>> 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-09 >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-09 >>> >>> >>> 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
Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls
Hi Evan,
I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just
plain X.509). What’s your plan for introducing OAuth and mtls?
kind regards,
Torsten.
> Am 13.11.2018 um 00:59 schrieb Evan Gilman :
>
> Thank you everyone for the feedback.
>
> I am currently working on the sample text, and should be complete in
> the next couple days. Apologies for the delay.
> On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell
> wrote:
>>
>> Sure, I think they could be treated as different different
>> client_auth_methods. But there is a lot more commonality than differences to
>> the point where I think it makes sense to keep it all in a single document
>> and under a single client auth method with just the variation on which name
>> is being used.
>>
>> On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer wrote:
>>>
>>> Would it make sense for these to be a different client_auth_method
>>> entirely? Much the same way that we have private_key_jwt and
>>> client_secret_jwt today, both of which use the JWT assertion framework but
>>> have very different keying and security assumptions. In the same way, here
>>> you’re still validating the cert but the means by which it’s validated is
>>> different, so the auth method is arguably not going to benefit from being
>>> overloaded. Caveat, I’ve not built out a system using SANs in any
>>> meaningful way.
>>>
>>> If we were to do that, this draft could go forward as-is (since it’s fairly
>>> done in my opinion) and a new document could better define the semantics
>>> for the various SAN types, but while building on the framework and concepts
>>> listed in here.
>>>
>>> — Justin
>>>
>>> On Nov 6, 2018, at 3:52 PM, Evan Gilman wrote:
>>>
>>> Response(s) inline
>>>
>>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden
>>> wrote:
>>>
>>>
>>> Is there an intention that any semantics are attached to the SAN being a
>>> URI or DNS name or IP or ...? Or is it still intended to be an opaque
>>> identifier?
>>>
>>>
>>> There are some extra things we could do if we attached type-specific
>>> semantics to the matching (e.g. DNS wildcarding etc), however I think
>>> that continuing to use the values as opaque identifiers would get us
>>> most of what we need while keeping things simple.
>>>
>>> On 6 Nov 2018, at 01:55, Brian Campbell
>>> wrote:
>>>
>>> Thanks Evan for bringing this to the WG's attention. More or less the same
>>> question/issue was raised yesterday in the area director's review of the
>>> document as well. I plan to bring this up as a discussion item in the
>>> meeting today. But my sense from some early discussions is that there is
>>> likely to be (rough) consensus to make some change in order to allow a SAN
>>> to be specified as the certificate subject identifier in the PKI client
>>> auth mode. We'll need to figure out the specifics of how that works. I
>>> don't think there are significant drawbacks to extending the number of
>>> client registration metadata parameters per se. I guess I've just been
>>> attracted to the idea of overloading the existing value because that felt
>>> like maybe a less invasive change. But perhaps that's shortsighted. And
>>> there's nothing inherently wrong with additional client metadata parameters.
>>>
>>> I don't know if we could get away with a single new parameter that could
>>> carry the value for any SAN type. Something like, { ...
>>> "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I
>>> feel like that'd probably be okay but in theory there's the potential for
>>> confusion of the value across different types. So probably there's a need
>>> to indicate the SAN type too. Either with more client metadata parameters
>>> like tls_client_auth_san_uir, tls_client_auth_san_email,
>>> tls_client_auth_san_ip, etc. or maybe with a structured value of some sort
>>> like {... "tls_client_auth_san": {"type":"URI",
>>> "value":"spiffe://trust-domain/path"} ... }. And then deciding which types
>>> to support and if/how to allow for the extensible types.
>>>
>>>
>>> I am far from an authority here, but it is my understanding that one
>>> of the primary drivers in supporting SAN over Subject is that the
>>> values are strongly typed. While some of the advantages gained from
>>> this may be less useful in our own context, I feel that it make sense
>>> to keep the values separate and not overload a single value. Whether
>>> that means dedicated metadata parameters or a structured parameter
>>> value, I am not sure what the tradeoffs would be, but both options
>>> sound suitable to me.
>>>
>>> Anyway, those are just some thoughts on it. And it'll be discussed more
>>> today. Suggested/proposed text is always helpful though (even if it's not
>>> used directly it can help move the conversation forward and/or help
>>> editor(s) to have prospective wording).
>>>
>>>
>>> Great. I will work on some sample text since it sounds like that would
>>> be generally he
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt
> > Does this "MUST be single-use” not effectively already require the code > is invalidated after first use? If so why downgrade this to a “SHOULD”? > > You are right. My feeling is single use can turn out to be a really hard > to implement requirement. That’s why I would like to relax it. Given we now > have a stronger requirement on client authentication that should be fine. > > Question to the list: what is your implementation experience regarding one > time use authorization codes? > There's a bit of discussion about this on this ticket in the Connect WG: https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-single-use FWIW. I do think that in some systems or architectures it can be difficult to strictly guarantee that a code can only be used once. And it'd be better for specs to come to terms with that rather than being unrealistically strict about it. We have an AS implementation that does do strict one-time use of the code. But it comes at a cost including some difficulties with resiliency for any particular code. Not to mention some troubleshooting and support issues/questions about it. We haven't gotten to the point of changing anything but have, from time to time, considered changing the implementation approach for code to something that would appear to behave the same but might not 100% guarantee a code could only be used once. -- _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
Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant
Ok, thanks for the clarification. Your point about a user with multiple devices is correct - but it is by design. The goal of this protocol is to allow device authentication - there is no information about the user. Therefore, there is also no way to associate devices to a user. It creates challenges, but it also opens new opportunities - for cases when there is no need in user entity, only strong authentication solution. Could you elaborate more about why do you think that "the private key protections you have in place are a net positive"? Finally, yes, it's just a small change to JWT client assertion, that make it more usable on physical devices. On Mon, Nov 12, 2018 at 3:19 PM Dick Hardt wrote: > I understand better, thanks! > > From an OAuth perspective, this is a client credentials grant. You have > added some other checks that may or may not help the security profile, but > at the core, you have a private key on the device that is the primary > credential, and is device oriented. > > FWIW: there are a number of usability challenges with your approach. The > user can't use more than one device. If they change devices, they lose all > their data. Also, IMHO, I don't think the private key protections you have > in place are a net positive. > > > > > On Mon, Nov 12, 2018 at 3:08 AM Omer Levi Hevroni > wrote: > >> Ok, let me try. >> >> At the company where I work, we have an app that is used by our users. We >> want to have a way to authenticate the requests from the application, >> without requiring the user to perform any interactive login flow. I >> described it more in-depth in the blog post - >> https://blog.solutotlv.com/userless-mobile-authentication/ >> >> Does this help? >> >> Also, thank you for your time and feedback. I appreciate it! >> >> On Fri, Nov 9, 2018 at 1:54 AM Dick Hardt wrote: >> >>> More detail on the scenario would help. >>> >>> On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni >>> wrote: >>> Yes, that is correct. I'm sorry the confusion, I think this confusion is built into oauth framework itself. You understood well the scenario - I have an application running on an untrusted device in an untrusted network. I looked for a way to authenticate the requests from the device to AS. Does it make more sense now? On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt wrote: > Omar > > As promised, I have reviewed the ID[1] you posted. I'm confused in the > Motivation by the references to authentication, as OAuth is about > authorization. > > Perhaps you can post to the list the use case you are trying to solve > for? I can infer aspects, but don't fully understand it. > > From what I can understand though, there is software running in a > trusted device that would like to get an access token, and an OTP is part > of how the device is authenticating to the AS. This seems like a 2 legged > OAuth flow as there is no user involved directly, and it seems you have a > means for the client to authenticate to the AS using an OTP. Am I guessing > correctly? > > /Dick > > [1] > https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
Hi Brock, > Am 09.11.2018 um 21:22 schrieb Brock Allen : > > Hello all -- > > I also have some thoughts/feedback on this document. > > Personally I agree with some of the conclusions, but as it stands I think the > document's main conclusion that code flow is the real solution is not > sufficiently convincing. > > I would like to see a brief summary of the current concerns (much like > RFC8252 does) so we have context before the document just jumps to what a > best practice is. The reason I bring this up is that generally the concept of > "best practice" is meaningless without context. I think stating that code > flow is best practice without motivation seems somewhat "cart before the > horse". > > I think just a short blurb about the desire to eliminate the access token > from being delivered in the URL, and the current attacks against doing so > would be helpful (showing attacks is super important in making this "real"). > I guess this would make the most sense in section "4. Overview" prior to the > list of "best practice" conclusions. > I agree, justifications are needed. As draft-ietf-oauth-security-topics-09 provides those justifications, I suggest to add suitable references here. > Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into > specifics, but many of the points seem confused (or at least confuse me) > and/or the conclusion that code flow is the only approach seems misleading. > For example: > > "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required > according to Section 6), so clients and authorization servers MUST NOT use > the Implicit Flow for browser-based apps.“ Don’t understand the wording either. The text should state that the implicit cannot detect token injection. > > This is specious. The threat is the token is in the URL, not that implicit > clients can't use PKCE. So perhaps the document should explain the variety of > mitigations, not just one? While code flow is one, using CSP and the browser > history API to remove the token from the URL is another. Helps to prevent leakage, not injection in the authorization response. > Elsewhere in the document the use of CSP is a "SHOULD". That's great, but > using CSP can be and is used today, and doesn't necessitate code flow. > > "OAuth 2.0 provides no mechanism for a client to verify that an access token > was issued to it, which could lead to misuse and possible impersonation > attacks if a malicious party hands off an access token it retrieved through > some other means to the client." > > Sure, but OIDC does provide a mitigation for this (even with implicit). This is about token replay detection at the RS. What mitigation does OIDC provide here? > So perhaps it should be offered as a suggestion as well? I did see the point > that with code flow id_token validation could instead rely upon the token > endpoint, but the client still has other work to do (namely around PKCE). > That's just trading one bit of work for another, not a clear cut reason to > use one flow over another. > > "Supporting the implicit flow requires additional code, more upkeep and > understanding of the related security considerations, while limiting the > authorization server to just the authorization code flow simplifies the > implementation." > > As offered by someone else already, this is opinion and not objective. IMO, > this diminishes the potential of this document. > > "If the JavaScript application gets wrapped into a native app, then [RFC8252] > also requires the use of the authorization code flow." > > Given how many browser dependencies SPA apps tend to have, is this really > common? In all my years building both, I've never seen it. > > "Historically, the Implicit flow provided an advantage to single-page apps > since JavaScript could always arbitrarily read and manipulate the fragment > portion of the URL without triggering a page reload. Now with the Session > History API (described in "Session history and navigation" of [HTML]), > browsers have a mechanism to modify the path component of the URL without > triggering a page reload, so this overloaded use of the fragment portion is > no longer needed." > > While this section is intended to indicate the existence of the history API > is a reason to move away from implicit, it's also what can be used to protect > token exposure in the URL, which I think weakens its point. As a section, to > me, it seems unnecessary. > > The push to a single flow (for consistency) is a marginal motivation, and I > agree with that theme in the document. > > Much of the other guidance in this document is already covered elsewhere > (e.g. RFC6819). I don't know if the goal of the document is to reproduce > those existing recommendations (as a contrast RFC8252 does not and mainly > focuses on what's unique to the native scenario). > > I can't quite tell the real motivation for this "best practice" doc
