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