Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

deviceauth: accepting a particular auth set should automatically reject all other out sets of that device

Description

When accepting an authorization data set of a particular device, other auth sets should be invalidated (i.e. rejected). This does not happen now, and it's possible that the device will obtain a token using and older auth set (eg. device does a key rotation, the new auth set gets accepted, but the device will still be able to get a token using the older key).

This work covers:

  • fixing deviceauth logic, steps:

    1. list all auth sets

    2. update db and reject all auth sets but the one that got accepted

    3. update db and accept the remaining auth set

  • trying to minimize the impact of not having transactions at DB level

  • adding migration

    • verify that timestamp works and if so migration shall switch all but the most recently updated accepted auth sets to rejected state

    • otherwise we should discuss how to identify the auth set that should be accepted

Affects versions

Environment

None

Checklist

Activity

Show:

Maciej BorzeckiSeptember 25, 2017 at 9:29 AM

I tend to have the same opinion as , basically if a device rotates the keys, then accepting new auth set will reject other auth sets, so this is covered. If there is no key rotation, then there'll probbaly the only one authset, in which case there's no problem.

I'm marking this task as done and we can perhaps revisit the discussion when we have more input about in-field use.

Maciej BorzeckiSeptember 25, 2017 at 9:08 AM

Marcin ChalczynskiSeptember 22, 2017 at 1:57 PM

re: migration

I had to dig into this after a long time, so I may be wrong, but:

  • personally, I'm ok with skipping the migration

  • the only driver for it would be a vague security argument - which may or may not apply

if we don't migrate, and some devices have already rotated keys (so >1 authsets) - then until the next rotation, all of them will be valid, right?

that's a problem only if users rotated the keys for actual security reasons - compromised production key that they never ever want to allow. IMO we can safely assume that this didn't happen.

MaciejSeptember 22, 2017 at 11:30 AM

If this will get migration I would suggest to skip back-port (risk for simple patch release).
This sounds like a behaviour change, perhaps next minor would be the way to go for introducing this?
For migration itself I have not much input, ?

Maciej BorzeckiSeptember 21, 2017 at 9:12 AM

Guys, I know that I've added migrations to the scope of this task, but is there really a need to add migrations? When the device will rotate the key, the user will have to accept a new auth set and thus all already-accepted auth sets will become rejected. In case of SaaS, it's a new installation, so there will be no old data that needs to be migrated anyway.
Thoughts?

Fixed

Details

Assignee

Reporter

Labels

Story Points

Priority

Sprint

Backlog

yes

Zendesk Support

Checklist

Created September 7, 2017 at 11:51 AM
Updated September 25, 2017 at 9:29 AM
Resolved September 25, 2017 at 9:29 AM