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
