Re: [OAUTH-WG] OTP-flow use case (sharing energy data)
Nope, device flow still requires interactive login flow from the user, just on another device. My flow aims for strong device authentication, without any user interaction. My flow has some similarity to oauth client assertion flow - https://tools.ietf.org/html/rfc7523, with modifications for mobile/IoT devices. On Tue, Jan 15, 2019 at 11:05 PM Samuel Erdtman wrote: > To me this looks similar to the device flow. > > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 > > See figure 1, my interpretation of what you want to do is to split up step > B so that the code goes via another channel and then revers the direction > of C and D. > > So maybe you could ride on some of the work done in the device flow draft. > > > > > > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler 40utilityapi@dmarc.ietf.org> wrote: > >> Howdy, >> >> Rifaat recommended I post to the mailing list. Specifically, I am looking >> for a mentor and feedback on a potential new OAuth flow (currently called >> OTP-flow). >> >> Background: >> I am a participant in the California Public Utility Commission's Customer >> Data Access Committee (CPUC CDAC), and we are working on improving utility >> data access to accelerate deployment of more renewable and energy >> efficiency technologies to fight climate change. >> >> However, we are currently struggling with a use-case for which we can't >> seem to find a good OAuth flow. >> >> Use-case: >> Utility customers want to share their utility data (e.g. historical >> energy usage) with a client (e.g. an energy auditor, to perform some energy >> efficiency analysis). >> >> However, there are two problems that often occur: >> >> 1) Most utility customers do not have online accounts or forgot their >> login information. This makes typical OAuth user interface complex, since >> you have to either create an online account in the flow or do some sort of >> multi-step password-reset/verification process. >> >> 2) Utilities are not strongly incentivized to optimize complex UI/UX for >> the customer in the authorization server interface. In the committee we've >> gotten to the point where we have to specify number of clicks, div height >> requirements, and minimum pageload times for a utility to implement their >> OAuth flows (and then utilities want to charge rate payers for the cost of >> each UI/UX improvement). >> >> So, we have been brainstorming possible ways around these problems, and >> we think it may require a new type of authorization flow using one-time >> passcodes (OTP) instead of redirecting the user to the utility for normal >> OAuth. Luckily, even though utility customers may not have an online >> account at the utility, the utility usually still has (a) a way of uniquely >> identifying them and (b) a way of contacting them (phone, email, etc.). >> >> I'd like to see if the OAuth working group is an appropriate place to >> help develop this flow (or if there has already been work done such a >> flow). I'm happy to write the initial draft, but I would very much >> appreciate some mentorship from someone more experienced in the workgroup. >> >> OTP-flow diagram and example: >> https://pastebin.com/raw/4Gx8LAQ1 >> >> The OTP-flow (called Solution 1b in the committee) is a mix of OAuth >> device-flow and authorization code flow. Since we want to avoid asking >> utilities to implement complex authorization interfaces (problem #2 above), >> the client asks the utility to send the user_code directly to the user (via >> text/phone/email), then the client asks the user for the user_code and >> submits it to the utility to get an access token. >> >> Also, there is an initial step of identifying (but not authenticating) >> the user and determining the way in which the OTP code should be sent. If >> utilities are given some sort of non-secret user identification (e.g. >> address, phone number, account number, etc.), they should be able to send a >> user_code to the user that the user can give to the client for >> authorization. Hopefully, this can shift most of the complex UI/UX >> development cost away from the utility and onto the third party clients. >> >> Unfortunately, the energy industry can be quite behind on the latest and >> greatest OAuth developments, but we're trying to get better :) >> >> Thanks very much, >> Daniel Roesler >> dan...@utilityapi.com >> >> ___ >> 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
[OAUTH-WG] Potential new OAuth client assertion flow
Hello My name is Omer, and I am working at Soluto. We wanted to find a way to authenticate our mobile application, without any user interaction - as this will affect the user experience. We developed a new authentication flow, similar to JWT client assertion. I've gave a talk about this flow in a few conferences, and the main feedback was that it is interesting enough to consider writing a RFC about it. Currently I'm looking to hear more opinions before starting to write RFC - so any feedback will be appreciated. I'm also looking for someone to help me getting started and reviewing the RFC - if you're interested let me know. To find more about this solution: - This is a blog post describing it: https://blog.solutotlv.com /userless-mobile-authentication/ - This is a link to the slides (recording should be available soon): https://www.slideshare.net/SolutoTLV/authentication-w ithout-authentication-appsec-california Thanks Omer ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Potential new OAuth client assertion flow
Yes, this is my intent - adding a new client assertion (currently the name I am thinking of is jwt-otp-assertion). The blog post was on how to do that by using existing OAuth/Open id flows. On Thu, Feb 15, 2018 at 4:37 PM, Vladimir Dzhuvinov wrote: > Hi Omer and welcome to the Oauth WG, > > On 14/02/18 22:48, Omer Levi Hevroni wrote: > > Hello > > My name is Omer, and I am working at Soluto. We wanted to find a way to > > authenticate our mobile application, without any user interaction - as > this > > will affect the user experience. We developed a new authentication flow, > > similar to JWT client assertion. I've gave a talk about this flow in a > few > > conferences, and the main feedback was that it is interesting enough to > > consider writing a RFC about it. > > Currently I'm looking to hear more opinions before starting to write RFC > - > > so any feedback will be appreciated. I'm also looking for someone to help > > me getting started and reviewing the RFC - if you're interested let me > know. > > To find more about this solution: > > - This is a blog post describing it: https://blog.solutotlv.com > > /userless-mobile-authentication/ > > - This is a link to the slides (recording should be available soon): > > https://www.slideshare.net/SolutoTLV/authentication-w > > ithout-authentication-appsec-california > Looks like a neat protocol to maintain a continuous auth session between > client and AS. > > Did you take a look at https://tools.ietf.org/html/rfc7523#section-2.1 ? > > This may be more suitable to pass the JWT, rather than tunneling it via > the password grant. > > Vladimir > > > ___ > 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-WG] First version (pre-draft) of OAuth 2.0 seamless protocol
Hey and Good Morning I've created a first version of the draft, hope to finish it and send a draft soon. This is the protocol I'm going to present on Wednesday OAuth WG meeting. Feedback is highly appreciated - this is the first time I'm writing a draft. You can find it here: https://soluto.github.io/oauth-jwt-otp-client-assertion/draft-oauth-jwt-otp-client-assertion.html Also the name is still work in progress. Thanks Omer ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2.0 Seamless Flow - first draft
Hey After presenting the flow yesterday, I've submitted the first draft: https://tools.ietf.org/html/draft-seamless-flow-00 I tried to answer all the question that raised during the session. Looking forward to hear your feedback. Omer ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: New Version Notification for draft-hevroni-oauth-seamless-flow-00.txt
Good afternoon :) I've submitted the draft again, this time with the WG name in it. Would appreciate review and feedback. Thanks Omer -- Forwarded message -- From: Date: Sun, Mar 25, 2018 at 7:08 AM Subject: New Version Notification for draft-hevroni-oauth-seamless-flow-00.txt To: Omer Levi Hevroni A new version of I-D, draft-hevroni-oauth-seamless-flow-00.txt has been successfully submitted by Omer Hevroni and posted to the IETF repository. Name: draft-hevroni-oauth-seamless-flow Revision: 00 Title: Seamless OAuth 2.0 Client Assertion Grant Document date: 2018-03-25 Group: Individual Submission Pages: 10 URL:https://www.ietf.org/internet-drafts/draft-hevroni-oauth- seamless-flow-00.txt Status: https://datatracker.ietf.org/doc/draft-hevroni-oauth- seamless-flow/ Htmlized: https://tools.ietf.org/html/draft-hevroni-oauth-seamless- flow-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hevroni-oauth- seamless-flow Abstract: This specification defines the use of a One Time Password, encoded as JSON Web Token (JWS) Bearer Token, as a means for requesting an OAuth 2.0 access token as well as for client authentication. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: New Version Notification for draft-hevroni-oauth-seamless-flow-01.txt
Hey New version of the draft published. Looking forward to hear feedback about it. -- Forwarded message - From: Date: Thu, Aug 2, 2018 at 12:15 PM Subject: New Version Notification for draft-hevroni-oauth-seamless-flow-01.txt To: Omer Levi Hevroni A new version of I-D, draft-hevroni-oauth-seamless-flow-01.txt has been successfully submitted by Omer Hevroni and posted to the IETF repository. Name: draft-hevroni-oauth-seamless-flow Revision: 01 Title: Seamless OAuth 2.0 Client Assertion Grant Document date: 2018-08-02 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-hevroni-oauth-seamless-flow-01.txt Status: https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/ Htmlized: https://tools.ietf.org/html/draft-hevroni-oauth-seamless-flow-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-hevroni-oauth-seamless-flow Diff: https://www.ietf.org/rfcdiff?url2=draft-hevroni-oauth-seamless-flow-01 Abstract: This specification defines the use of a One Time Password, encoded as JSON Web Token (JWS) Bearer Token, as a means for requesting an OAuth 2.0 access token as well as for client authentication. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Presenting Seamless Flow at IETF 103
Hey My name is Omer, and I want to ask a time to present a draft I'm working on at IETF 103. This is a new oauth extension, that suppose to allows devices to authenticate without any user interaction. There are many use cases, especially in IoT world, where there are devices which need a strong authentication solution - but does not have an option for any kind of user interaction. This flow intends to allow them to achieve this. The current version of the draft can be found here: https://tools.ietf.org/html/draft-hevroni-oauth-seamless-flow-01. Feedback on the draft is highly appreciated. Thanks, Omer ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Presenting Seamless Flow at IETF 103
Hey James, Thanks for the feedback! Your counter suggestion is what called usually "Counter-based OTP". It might not be clear from the draft, but using a counter can result in devices that are locked-out. As you mentioned, this can be solved by a more lenient server - but this also weakens the protocol. And as lenient as the server can be, devices can still get out of sync. This draft aims to propose an alternative OTP solution that is tolerant to out of sync devices and allows a mechanism to unlock devices. Does this answer your question? Should I clarify this in the draft? 64 bits/bytes - my mistake. I was referring to unsigned long, which is 4 bytes. I filed an issue <https://github.com/Soluto/oauth-seamless-flow/issues/3> - will fix later. Client Id - This is the identifier of the device using this app, not the key. Also, client id is a well-known term in OAuth and I preferred to use it for clarification. Previous/Next/Current/New - noted, will fix - I filled an issue <https://github.com/Soluto/oauth-seamless-flow/issues/4>. Thanks! One Time Password (or OTP) - I used it as a reference for the general idea of OTP, not the specific algorithm Seamless flow - name is temporary, and I'm open for suggestion. It comes to clarify that it's a flow that allows "silent" login, without any interaction. This is why I choose "seamless". Does this makes sense? On Tue, Sep 18, 2018 at 4:29 AM Manger, James < james.h.man...@team.telstra.com> wrote: > Comments on draft-hevroni-oauth-seamless-flow-01: > > > > This draft seems to be about making crypto signatures stateful so you have > a better chance of detecting a cloned key as its state will diverge from > the original. > > The link to a seamless OAuth flow seems tangential. > > > > A more common way to make signatures stateful is to add a counter. A > counter is more predictable to an attacker, but it also allows some > recovery from an occasional outage that loses one signature (eg accept only > the very next counter value, or be a bit lenient and accept a counter value > as long as it doesn’t repeat or go backward). > > > > An attacker who clones a key can forge any number of signatures whenever > they see 1 signature from the original user: just re-use the same “next” > value (or send a bunch of signature where the last one re-uses the original > “next” value). > > > > > > * “Each of those numbers can hold signed int, up to 64 bytes length” > > 64 bytes or 64 bits? > > If you are using integers in JSON you better stick to 53-bits, which the > limit for exact integers in a 64-bit float [RFC7493 I-JSON > <https://tools.ietf.org/html/rfc7493#section-2.2>]. > > But in this situation you should just use strings. All you are using is > randomly chosen previous and next values that you can do equality matching > on. > > > > * “client-id” > > You already have a key-id for the JWS signing key so I’m not sure what > extra a client-id just for the prev/next state adds. > > > > * “previous”, “next”, “current”, “new” > > I think 4 labels are used for 2 quantities. > > > > * RFC2289 A One-Time Password System <https://tools.ietf.org/html/rfc2289> > > Are you actually using the referenced RFC2289 (that seems to use > H(H(H(H(…H(password + challenge + stuff)…)? > > I don’t think so. I think you are using normal crypto signing keys, plus a > random nonce. > > > > -- > > James Manger > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Omer Levi > Hevroni > *Sent:* Tuesday, 18 September 2018 5:40 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Presenting Seamless Flow at IETF 103 > > > > Hey > > My name is Omer, and I want to ask a time to present a draft I'm working > on at IETF 103. This is a new oauth extension, that suppose to allows > devices to authenticate without any user interaction. There are many use > cases, especially in IoT world, where there are devices which need a strong > authentication solution - but does not have an option for any kind of user > interaction. This flow intends to allow them to achieve this. > > The current version of the draft can be found here: > https://tools.ietf.org/html/draft-hevroni-oauth-seamless-flow-01. > Feedback on the draft is highly appreciated. > > > > Thanks, > > Omer > > > ___ 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
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] questions on Seamless OAuth 2.0 Client Assertion Grant
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] 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
