Subject: [Tools-discuss] Auto-posting IESG ballots

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Oct 2017 06:52:59 -0700

Hi folks.

I've been working some more on my IETF review tools and I'm now at the point
where I want to take an external review and hoist it into the IESG Ballot.
Is there
an existing API surface for this kind of thing? Perhaps one which takes an
auth token
so no CSRF/cookie nonsense?

-Ekr

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2017 14:19:58 +0200

Hi Ekr,

> so no CSRF/cookie nonsense?

No, there isn't, but adding an endpoint for this isn't that hard.  There
are things ahead of it in the queue, though ,:-)

Best regards,

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Oct 2017 07:47:27 -0700

Thanks. I would actually be fine with replicating the existing API surface
(it's not that hard to generate form fills), as long as I could use an API
key rather than a cookie, because it's a real pain to replicate the
anti-CSRF logic.

-Ekr

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2017 16:54:36 +0200

> key rather than a cookie, because it's a real pain to replicate the

I'm fine with an API key as alternative to anti-CSRF, but would not like to
rely on only that for authorization.  Are you ok with doing a regular login
cycle to cookie storage ahead of posting to the form with the API key?

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Oct 2017 07:58:05 -0700

On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz <[email-masked]>
wrote:

> rely on only that for authorization.

I was thinking a per-user API token the way that (say) the Github API works.
Would that be a problem?

Are you ok with doing a regular login
> cycle to cookie storage ahead of posting to the form with the API key?

I could also do this as long as the  cookie was perpetual so I could log in
through
my browser and then store the cookie on the server. I'd like to avoid
having my
password on the server.

-Ekr

> >> > an existing API surface for this kind of thing? Perhaps one which
> takes
> >> an
> >> > auth token

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2017 17:31:03 +0200

On 2017-10-18 16:58, Eric Rescorla wrote:
> I was thinking a per-user API token

Yes, I assumed that.

> the way that (say) the Github API works.
> Would that be a problem?

I'll go and check the github API key details and the way they are used.

Essentially, what you're proposing is to use a combined authentication
and authorization token instead of username+password.  If that token
doesn't leak, it should not be a problem.  If it leaks, it's of course
a potential problem.

One property of API keys is often that they have a limited lifetime,
in order to reduce the impact of leakage.  Given what you write below,
I guess that's a property you would like to avoid, too?  Or would that
be acceptable?

> I could also do this as long as the cookie was perpetual so I could
> log in through my browser and then store the cookie on the server.
> I'd like to avoid having my password on the server.

Understood.

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Oct 2017 08:37:51 -0700

> doesn't leak, it should not be a problem.  If it leaks, it's of course

Right, but of course that's the situation for a password as well.

> I guess that's a property you would like to avoid, too?  Or would that

Yes, I would like to avoid that. The invariant I want to have here is that
I can provision the bridging server (the one that moves data back and
forth between phabricator and the data tracker) with credentials for
each side and then let it run indefinitely. At the end of the day,
one might imagine merging that logic into phab or the datatracker
or both, but because you want to avoid polling, the upshot will
still be distribution of credentials.

-Ekr

> >> >> > I've been working some more on my IETF review tools and I'm now at
> the
> >> >> point

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2017 20:43:39 +0200

> Right, but of course that's the situation for a password as well.

Agreed, but you clearly aim to limit exposure of the password more
strongly than the API key.  To counterbalance this, I believe the
API key should be limited in what it authorizes the holder to do.
More below.

> still be distribution of credentials.

Right.

Ok, so in order to limit the damage an exposed API key can do, here are
some thoughts:

 * Provide a GUI to revoke a key (necessary in any case) and give
   an overview of existing keys and their usage.

 * Time limit the validity of the key to N days (30?) from the time of
   the latest login to the datatracker using username+password.

 * Limit the key to a given URL path prefix (e.g., /api/iesg/ballot/)
   This means having multiple keys if we evolve additional API endpoints,
   which I expect to happen.

 * Provide regular information in the datatracker GUI about API key
   activity in a manner easily digested and minimally distracting.
   Maybe a message once a week, summarising the activity?

Thoughts?

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Oct 2017 11:50:55 -0700

On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz <[email-masked]>
wrote:

> >> >> > (it's not that hard to generate form fills), as long as I could
> use an
> >> >> API

This seems conceptually fine.

>    an overview of existing keys and their usage.

This seems like a good plan.

>    the latest login to the datatracker using username+password.

Yeah, this seems like it would probably work though might be brittle.

>    Maybe a message once a week, summarising the activity?

Both of these seem like good ideas.

-Ekr

> >> >> >> > where I want to take an external review and hoist it into the
> IESG
> >> >> >> Ballot.
> >> >> >> > Is there

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Oct 2017 16:35:38 -0400

>   Maybe a message once a week, summarising the activity?

The API key needed to be bound to a particular role (like AD), and if the user looses that role, then the API key needs to be revoked by the datatracker automatically.  I just think this means that there are a series of checks that are made when the API key is used, and if any of the checks fails, then the API key gets flushed.  Future attempts to use the API key lead to "unknown API key".

Russ

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2017 22:46:12 +0200

Ok, good.  I expect to talk priorities and task queue with Russ shortly.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2017 23:00:36 +0200

Hi Russ,

On 2017-10-18 22:35, Russ Housley wrote:
> The API key needed to be bound to a particular role (like AD), and if
> the user looses that role, then the API key needs to be revoked by
> the datatracker automatically. I just think this means that there are
> a series of checks that are made when the API key is used, and if any
> of the checks fails, then the API key gets flushed. Future attempts
> to use the API key lead to "unknown API key".

Ack on adding flushing on misuse to the list of possible restrictions.

Regarding the role part, my thought was to handle that not by binding
the key directly to the role(s), but rather to handle the role transitively
through the user.  Get the user from the key, and apply the usual role
checks we have for different operations to the roles the user has at the
moment.  That handles role validation the same way as when doing an
operation through a form.

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Oct 2017 14:15:25 -0700

On Wed, Oct 18, 2017 at 1:35 PM, Russ Housley <[email-masked]> wrote:

> The API key needed to be bound to a particular role (like AD), and if the
> user looses that role, then the API key needs to be revoked by the
> datatracker automatically.  I just think this means that there are a series
> of checks that are made when the API key is used, and if any of the checks
> fails, then the API key gets flushed.  Future attempts to use the API key
> lead to "unknown API key".
>

That would be OK, but why not just bind it to the user and then have it go
through the standard access control checks.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Oct 2017 17:25:31 -0400

> On Oct 18, 2017, at 5:00 PM, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Russ,
> 

I think we are getting to roughly the same design.  Some URLs require a particular role for a database update to be authorized.  We agree that those checks must still be made, and that a failure should prevent the API key from being used in the future.

Russ

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 19 Oct 2017 03:53:45 +0200

On 2017-10-18 23:25, Russ Housley wrote:
> I think we are getting to roughly the same design.  Some URLs require
> a particular role for a database update to be authorized.  We agree
> that those checks must still be made, and that a failure should
> prevent the API key from being used in the future.

Right.

	Henrik