Subject: [OAUTH-WG] Presenting Seamless Flow at IETF 103

From: Omer Levi Hevroni <[email-masked]>
Date: Mon, 17 Sep 2018 22:39:44 +0300

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

---

From: "Manger, James" <[email-masked]>
Date: Tue, 18 Sep 2018 01:29:34 +0000

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:[email-masked]] On Behalf Of Omer Levi Hevroni
Sent: Tuesday, 18 September 2018 5:40 AM
To: [email-masked]
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

---

From: Omer Levi Hevroni <[email-masked]>
Date: Thu, 20 Sep 2018 19:46:45 +0300

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 <
[email-masked]> wrote:

> 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.
>
> 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).
>
>
>
>
>
> 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.
>
>
>
> * 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)…)))))?
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Omer Levi
> Hevroni
> *Sent:* Tuesday, 18 September 2018 5:40 AM
> *To:* [email-masked]
> *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
> https://tools.ietf.org/html/draft-hevroni-oauth-seamless-flow-01.
> Feedback on the draft is highly appreciated.
>
>
>
> Thanks,
>
> Omer
>
>
>