Skip to main content

Minutes IETF105: oauth: Tue 15:20
minutes-105-oauth-201907231520-00

Meeting Minutes Web Authorization Protocol (oauth) WG
Title Minutes IETF105: oauth: Tue 15:20
State Active
Other versions plain text
Last updated 2019-07-29

minutes-105-oauth-201907231520-00
Note taker: Aaron Parecki

Note Well presented

Current Internet Drafts
=======================

Chairs update:

JAR Draft
Nat: Concern of overlap of the claims between the JWT claims and OAuth request
parameters

JWT BCP
Mike Jones: 1 discuss, editors have been reviewing comments, trying to improve
the text

Introspection Response - good progress
Roman: some changes made based on AD review, can move towards last call after
last comment resolved

Key Distribution
Hannes: what happens when the key the client presents is not the same as being
used for authentication? needs some discussion this week

Token Exchange
approved, in editor's queue

Security Workshop
=================

Daniel Fett

4th edition of security workshop was in march in Stuttgart
three days of talks & discussions, lots of time to discuss in depth
started out as a venue to discuss security topics, but lots of other oauth/oidc
topics are discussed now latest workshop had some pre-scheduled sessions as
well as unconference sessions where do we hold the next events? +1 2020? *
Steinar Noem proposed Norway (Oslo or Trondheim) * Stuttgart - Group of Ralf
Küsters as a fallback when? nearby events: * IETF 107 Vancouver March 21-27 *
EIC May 12-15 Munich * IETF 108 July 25-31 Madrid

looking for other options, ~70 person capacity
* john bradley - computing science department at UBC (https://www.ubc.ca/)
in Vancouver may be interested

* +1 from Torsten (via jabber)
* Eve Maler - I can check on ForgeRock sponsoring in Bristol, UK - it does have
a (small) office in Oslo too - doesn't hold 70 people but maybe they can rent
something!

Reciprocal OAuth
================

Dick Hardt

added ascii art diagram to the draft
(walking through diagram)

who has read the document? ~4 raised hands

Mark McFadden: the current draft launches into this diagram immediately. it'd
be helpful to introduce the reader to a use case first. Is there another word
besides "reciprocal" that could be used instead?

Nat: on first reading, was not clear whether there are two resource owners
Dick Hardt: the use cases I am thinking of there is one resource owner, but
there may be other use cases that have more than one

Security BCP
============

Daniel Fett

draft 13

Refines and enhances security guidance in OAuth 2.0 core
Updated and comprehensive threat model, describing many attacks that have been
discovered in the last few years Also includes concrete and actionable
recommendations

Changes since last IETF meeting

* discourage the use of password grant (MUST NOT be used) because:
    * exposes credentails to the client
    * increases attack surface
    * not adaptable to modern authentication like webauthn or 2fa
*
input from Neil Madden
* there is a risk of the client impersonating a resource owner
* if the client uses dynamic registration and the client can influence the
"sub" value

Justin Richer: how? the client is not allowed to choose the client_id
dfett: assuming the client has some influence
Justin: recommend adding some language that clients should not be able to
choose their client_id

dfett: client SHOULD NOT be able to select the "sub" value

PKCE:
* we encourage the use of PKCE S256 instead of plain
* AS MUST support PKCE
* AS SHOULD publish PKCE support
* under certain conditions, PKCE MAY replace state for CSRF protection, in
which case you are free to use "state" to carry application state

Open Questions:
* make metadata mandatory?
  * clients can rely on PKCE only when they know the AS supports it (e.g.
  dropping state for csrf as previously
described)
  * could say AS SHOULD use metadata to announce support for PKCE, or MUST,
  which means RFC8414 is
mandatory

would this be a good idea?

John Bradley: mandating the use of metadata may be a step too far. may be safer
to say that if the server doesn't support PKCE, the client must use state for
csrf protection Vittorio: Aaron: could the AS announce support for PKCE in
documentation? dfett: could say MUST announce support for PKCE in discovery or
an implementation-specific way, which would include documentation

dfett: new attack discovered in stuttgart, we need to write something about it
"PKCE Chosen Challenge Attack" - circumvents PKCE
in order to launch the attack, the attacker needs to read the authz response
(leaked/logged URI), and an attacker needs to be able to bring the victim to an
arbitrary URI (diagram of attack in slides) possible solutions? token binding
(lack of support), form post response mode (potentially big change, not
suitable for apps), could check origin header at AS (but AS is a GET, no origin
header) possible new mechanism: IVAR Integrity Verification for Authorization
Requests * the AS needs to check that the AS request comes from the client not
from the attacker * the client in its metadata publishes its IVAR URI * the
client stores the authorization URI in web storage in the browser * the AS
opens an iframe from the IVAR URI and sends a postmessage to the iframe,
containing the AS request URI * the iframe checks the localstorage of the
client, sees the match, answers "ok" ensuring the integrity and origin of all
the data in the AS request URI while this seems like a big change, but isn't
really if JS is disabled, falls back and doesn't provide this protection Checks
the integrity/origin of state, nonce, request_uri, redirect_uri Protects
against three attacks: PKCE chosen challenge, manipulated redirect URIs, mixup
attack This is currently written up as draft-fett-oauth-ivar-00, would be
referred to by the Security BCP

John Bradley: this is the best bad idea we could come up with, the only
effective thing we could come up with than token binding. does run the risk of
being blocked by Safari's anti-tracking technology now or in the future dfett:
current policy from apple is if you interact with the website in a top-level
context and then the website is used in the third party context then it will be
preserved Annabelle: chrome and firefox are supposed to be blocking
localstorage when 3rd party cookies are disabled, so not just a Safari issue. i
would be nervous about this surviving future browser iterations Leif Johannson:
this ends up looking like an empty object in browsers Filip via jabber:
WebKit's ITP2.0 is famous to block the cross-origin access to localStorage so
disabled javascript isn't the *only* case a fallback would have to run for
Brian Campbell: there are similarities in how token binding works and dpop
dfett: DPop wouldn't help either Filip via jabber: rendering a blank page on
every authorization_endpoint to execute this just blows nice UX, that's a
concern to some

dfett: I will describe this attack in the Security BCP and discuss some
mitigations which may or may not include this mitigation

BCP is almost ready for publication?

Vittorio: "MUST NOT use ROPC" - but we need an answer for people who have no
alternative, e.g. SQL connection strings. if there is anything at all we can
suggest they can use instead, otherwise we are telling them they are in non-
compliance. maybe even saying if you are in these situations then OAuth is not
for you.

Hannes: I am uneasy that you brought up this new attack
John: it's an old attack and we decided to address it with token binding, but
given that may not be an option we came up with an alternative. so what's new
is the alternative not the attack. Hannes: I see this "ready for publication"
but feel uneasy about sending it over Roman: it seems weird to me that we're
declaring a BCP and having a lot of discussion about whether we agree on what
we said

Transactional Authorization (XYZ)
=================================

Justin Richer

OAuth started with two RFCs, but today it looks like this (pile of RFCs)
there's a lot of things to understand if you want to learn about OAuth, we're
building a lot of BCPs to guide people through the space we're also learning
that there are a lot of places that OAuth doesn't fit over the last year or two
been working on an experiment of what it would look like to re-think this
https://oauthw.xyz This is not an extension/profile to OAuth 2.0, that's on
purpose A lot of the problems of OAuth are because of the front channel There
is a long list of specs that exist to close holes that exist because of the
front channel This proposal started by saying let's only use the front channel
for very specific things when needed OAuth has always been transactional, what
I decided to do with this project is to make that transaction a key component
This is the Registering Intent pattern in use by many other specs today
Protocol outline:
    * client starts by talking to the AS over the backchannel, containing a
    bunch of information about what the client
can do
    * "what I want" (structured scopes, resources, etc)
    * "how to recognize the client" (a key, key reference) - may be a key the
    server knows before, or a key the client
generated on device. maybe sign the request body and present a header, lots of
ways to innovate this
    * "what the client is" - user visible information like name, URI. these are
    different from how to interact with the client * "what i know about the
    user" - this may be an assertion, verifiable credentials, username/password
    * "how I can interact with the user" - bridging to the front channel. how
    can I get the user there and how can I get
the user back? (e.g. I can redirect the user and handle this callback URL)
    * the AS now has enough information where it could potentially return an
    access token right now, or could say "I
need to talk to the user"
    * the AS can return an "interact URL" (unique per request, the client
    cannot modify it) * each step in the transaction points to the next, which
    helps close many attacks like mixup * the client sends the user to the URL,
    not adding any query parameters, not adding client ID, because all that was
sent in the back channel during setup
    * AS looks up the TX info in the unique incoming URL
    * The user logs in/authorizes/etc, then AS returns the user to the redirect
    URI * the transaction URL response also came with a transaction handle
    (analogous to the authorization code) * the client STILL has to prove
    possession of all referenced keys, and makes a request to continue the
    transaction * finally the AS returns an access token
handles everywhere
    * in response to an initial request with client information, the AS can
    respond with a handle that references this info
which can be used later
    * the access token can also come back with a transaction handle - like a
    refresh token * remembering or identifying the user - UMA persisted claims
    token - can use a user handle here for that * scopes: a way to say I want a
    slice of this API. can combine string based scopes with structured scopes *
    device flow works as well: "I can't send the user to a URL" so the AS
    returns a short URL to display to the user
and a short code they enter at that URL
    * device flow with combined URL? actually just the regular interact URL put
    into a QR code * what about identity? refer to Aaron Parecki's blog post
    https://aaronparecki.com/2019/07/18/17/adding-identity-to-
xyz
    * token binding - access tokens are bound to a key
Mapping to OAuth 2
    (diagram in slides)
Pros and Cons
    * pros: wider set of use cases, and the more legacy use cases I throw at it
    seem to fit * cons: not backwards compatible, this is not OAuth 2. we could
    do some of these things with OAuth as a base
(FAPI, DPOP), but this is drastically simplified
    * but these could likely be deployed side by side

Do we want to make this a working group item?
    * proposing that we work on this in parallel with the current OAuth 2.0 work
    * I am already deploying this with people because we hit cases OAuth 2.0
    can't solve

John Bradley: it incorporates a lot of what we've done in OAuth. OAuth probably
won't live forever. It is probably useful to adopt this as experimental, work
on it, get experience. But we don't want to signal to people that it's mature
yet. So hopefully by the time people hit boundaries of what they can't do with
oauth they will see this.

Neil Jenkins: this data model sounds good and worth looking at more. we use a
similar model for our authenticaiton flows.

Roman as AD: the wg can decide what it wants to work on, but we need to discuss
the charter

Annabelle: I want to call attention to none of the handle/workflow idea is
specific to authorization and there's an underlying protocol that is more
broadly applicable and worth breaking into its own thing.

Justin Richer: Maybe it's worth a new working group for this then

Roman: that's a possibility

Annabelle: what you have here is a mechanism for kicking the end user out to
another context to do something in a sefcure fashion. usually we think of that
as the user needing to authenticate or authorize, but that could be any number
of things like needing to fix up an expired credit card, anything where the
user needs to be sent ot a different context.

Justin Richer: that kind of thinking is why i've called it the interaction URI
not authorization URI.

Dick Hardt: this WG started with OAuth 1 then moved to OAuth 2. in 2, we tried
to keep semantics and thinking but it was a breaking change from 1. I would
agree with the reasons it needs to break. The challenge is going to be people
have a lot of stuff deployed. For us to get traction and people working on this
would be to capture the use cases of what we're doing -- addressing issues with
OAuth 2 -- but more importantly what are the use cases this solves that we
can't do with OAuth 2 to help drive adoption. Solving new use cases will help
bring energy to work on it as opposed to fixing something that works.

Justin: what's driving my work on this is a set of use cases where OAuth 2
doesn't work

Dick: we want to get clear on what we are trying to solve, then decide what is
in scope or not.

Jim: I would like to recommend rechartering here than building a new WG, I'd be
afraid of a new WG losing some of the collective knowledge