> Web Authorization Protocol (OAuth) Agenda (1) > ========================================= ----------------------------------- DAY 1 ----------------------------------- > > ---- 17:10-18:10 Monday Afternoon session III ---- > > * Welcome, Overview, Agenda Bashing -- Hannes Tschofenig - 15 minutes > * OAuth 2.0 Device Flow for Browserless and Input Constrained Devices - William Dennis - 15 minutes > (draft-ietf-oauth-device-flow) https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-device-flow-00.pdf leif: thinks it is not a good idea to provide the user_code in the verification URI on 9/16 william: said google probably won't implement this torsten: pushes back on the optional use of the user_code in in the verification URI or the use of QR code william: have heard this week that some folks will implement this, and it might be possible to come up with use case that can solve security concerns. leif: and/or have security concerns about this "here is why we arent putting this in the spec..." william: this might be useful to some devices, and this falls back gracefully as justin pointed out torsten: this type of attack is called "remote phishing" justin: need security considerations on this, and spelling out UX, best we could do if we include it is give an example william: this takes on slightly more risk, if u want this feature please say so justin: worth having a discussion whether this ought to be included -- he sorta has a use case but he can get by w/o it... lucy: sounds like you dont need this, we do not have enough data. we need to see a requirement before adding this. jbradley: have talked with industrial iot folks, and one of their reqs is to have more entropy in the code, they want to scan qr code lucy: need to document it and include it in the security consideration section tony: doesnt think this is scoped, folks doing this ad-hoc today... jbradley: this seems to fit some classes of the iot devices, should describe the devices that use it and risks then leave it in the spec. torsten: do ur codes expire once used first time? jbradley: not sure...., the code active during bootup and the code would be used multiple times and the user need to do something on the device. torsten: if the code is an identifier for the device then is different than the code in the spec. hannes: ought to discuss on mailing list william: thinks it could be done safely and useful... kathleen & hannes: discuss on mailing list... william: user is wanting to "authenticate" their device -- is a user-initiated action.... [moves on in preso] there's running code, see slides jim fenton: what about device authnz revocation? what happens when u dispose of the unit? william: most of these have a reset button which will clear this remembered stuff justin: do not confuse the device authz code with access token, notes that in earlier days the WG decided to not address revocation make it like clearing cookies > * The OAuth 2.0 Authorization Framework: JWT Pop Token Usage - Nat > (draft-sakimura-oauth-jpop-01) https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-jpop-00.pdf [see slides] jbradley: we oauth wg thought about this, thought token binding would solve, but banks are doing server-to-server and tls mutual auth, and are asking how they can bind oauth tokens to tls -- hence this spec [token binding works ok in consumer-facing client-server use cases] UK open banking s(?) need to do something now tony: we microsoft did some stop-gaps while waiting for tokin binding, so there's other approaches to consider, if this draft is accepted then microsoft will submit I-D(s) brian: way too many options in this --- can probably drop the conf methods -- ie scale the draft back... jbradley: we listed everything in IANA reg(s) -- agree with brian that we have one or two methods we actually do.... someone with verisign: reps IoT consorts, seeing a convg here to going to crypto groups of trust, dunno if this group has focused on an interactive authn -- ought to look at what other groups are doing, this wg needs to decide if u really want to go into this world. eg indust inet consort, etc, etc. see some convergence but oauth may not be good fit. hannes: see ACE WG, using oauth in that context jbradley: this is about device authn someone with verisign: the iot folks are interested in doing exactly that torsten: can you really nail down a use case? nat: the banks want to set up their own CAs and issue certs to the fintech companies, so fintech could use it to authenticate their clients to the authorization server and tie it to the token jbradley: the banks only care about disting names (DNs), they want oauth dynamic client registration with tradutional PKI [..discussion..] torsten: really do this on the banks timeline???? in a couple months? what's oauth WG role in thie game? nat: we should give some guidance on this... jbradley: we can have a draft to point them at... torsten: that will be bad because if they implement then down road "u cant change this" lucy: +1 to what torsten said hannes: but it is a good thing that they come to the OAuth WG to get help. reviewers: Brian, Torsten and Andy end ----------------------------------- DAY 2 ----------------------------------- here: http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-oauth?useMonospaceFont=true and included below: > Web Authorization Protocol (OAuth) Agenda (2) > ========================================= > > ---- 9:00-11:30 Friday Morning session I ---- > * OAuth Token Exchange - Mike Jones - 15 minutes > (draft-ietf-oauth-token-exchange) see slides https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-token-exchange-01.pdf torsten: why do we need mult audiences? thinks is too complex, token exchange is for server-to-server, just use token exchange multiple times is better practice tony: not just server-to-server, plus all downstream entities, cant reestab each time, many hops in chain, e.g. client to gateway to office365, etc. justtin: sounds like non-user-interactive, but machines are talking to eahc other, a server that has a token needs a new token for something else, that's what this is about... torsten and tony saying same thing mike: we do have use cases where a token is used one place and passed downstream to another place, and both places need to be an audience of the same token, ohterwise you have a security problem. torsten: that assumes that client knows the downstream chain, but they wont, so cant put aud in there. mike: there are use cases that we know that off365 may hand off a token to another antity downstream. john: understand torsten's architectural principle, and tony's legacy swamp. In aid of legacy, token promiscuity is arguably necesary, eg for microsofts's legacy stuff mike: btw this wg and iesg approved jwt spec w/multiple audiences... torsten: been working with john on security stuff lately, and audience is a critical concept, want to clean it up, we need to justify need for multiple audiences on per use case basis... mike: this is a general purpose token exchange, so different use case can describe their actual usage. justin: Has anyone managed to get the resource and audience fields in SAML correct? (Scott Cantor doesn't count)? thinks getting aud right is hard and many dont (and is a 'bad design' (?) eg in saml) ...we will have subtleties that can really mess things up john: yes, this can be misused, perhaps we need to write bcp document on it, we should encourage folks away from bearer tokens justin: [mentioned case wehre he counseled someones to try to get rid of "ubertokens" used for too many things] brian: an option thats there -- eg make this authorization server policy, and return an error code when the authorization server is unwilling to process those audiences/resources. tony: I am ok with this approach. mike: the error code is in draft hannes: bring this to mailing list and hash it out -- eg suggest clarifying text AI-- mike: brian - can u please point out the error code thing on the thread? brian: yes > * OAuth Authorization Server Metadata - Mike Jones - 15 minutes > (draft-ietf-oauth-discovery) https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-authorization-server-discovery-metadata-00.pdf see slide mike: this is baked/cooked -- request publicatoin? john: it is time no objections -- hannes will send to EKR torsten: has 2 comments will send to list > * OAuth Token Binding - Brian Campbell - 30 minutes > (draft-ietf-oauth-token-binding) https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-token-binding-00.pdf see slides open issues and next steps are on slide 14..17 Hannes asking for reviewers! -- implementors? mike: we are implementing brian: hans has done some impl work, web server token bound access codes, he is independent consultant justin: is still skeptical of token binding for various reasons -- about this, how does referred token binding work when in a native app when not starting with a redirect by a launching URL -- how does that referral work? john: for native apps, the token binding specs encourage platforms to expose proper APIs in HTTP , eg launch with a referred thing brian: not to the authorization endpoint, but to the token endpoint. It is up to the native up to piece it together make the call. hope for decent platform apis... john: [ things are still evolving, recounted some details of how the platf APIs may evolve, and how the web APIs may work...] justin: does not really alleviate concerns. brian: wondering about the signed referred TB in HTTPSTB spec, browser can be tricked in many ways, wonders how that will work out, but in native code case things are much more controlled and thinks its applicability will be greatly expanded. tony: would be good to hear back from folks wrt paltform API features ought to be provided. have you done this in java? brian: yes, on server side. on client side will be difficult tony: jsee will need to support rfc5705 (?) the keying material brian: have implemented that and it was a bit hairy. this is a bit of a long game, lots of pieces need to line up hannes: at hakathon, william and john were working on some of this stuff brian: sent demo link to unbearable list will send to oauth list too john: native application best practices work may help for API design.... dirk: agrees with ereasoning wrt that is not scary -- wrt binding access token when the refresh token is not bound, open issue #3, if the refresh token is a bearer token, then there is no point in binding the refresh token. hannes: if the attacker can get the refresh token, they can just mint new access tokens brian: there is a fundament difference between client types, probably should only issue bound accces tokens upon receiving bound refresh tokens in native case -- in web case these refresh tokens are already bound to the client autnetication. dirk: if refresh tokens are protected via some other means, then things ok brian: no way now to tell the server to bind the access token but not the refresh token hannes: potential of getting something wrong is high, need to think it through well. brian: once the token binding functionality is in there properly then will not be so complicated mike: we are trying to use the token binding protocol to convey token binding info rather than at app layer parameter -- part of reason to write this all down is forcing function end2end so libraries and platforms will build APIs to use provided and referenced token binding in a general way, if there's a case where we can not convey token binding using extension, then will add params to APIs to allow it... brian: reasonabley confident won't need to do that. not decided, but a param at token endpoint may be needed. mike: ok we will need to discuss john: hopefully when google turns on token binding for refresh toks and things break we will learn and figure it out -- the road forward will become clear as we try this stuff, and in some environments the referred-tok-bind header may not work -- eg in native app, it can do something diff than referred token binding.... hannes: need more review of this draft. dirk the only reviewer > * OAuth Security Topics - Thorsten Lodderstedt > (draft-lodderstedt-oauth-security-topics-00) https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-security-topics-02.pdf see slides Jb: not proposing to eliminate redirect URI, moving responsibility to client tl: yes. using pkce challenge is more effective -- some oauth impls do not do it, or do not do it correctly jr: overall this is great, have read doc, tho the AS-spec redir URI -- what does that solve that ? & pkce dont solve? tl: as-specific uri matching solves case where ? tries to be a client (?) -- client needs to memorize which AS is using (?) -- pkce spec does not address this we think..but if it does pls give feedback tl: this doc gives minimum countermeasures impls and deployments should employ but need review and feedback yaron sheffer(ys): suggest u rename to "recommendations" from "topics" tl: is "topics" for now cuz is a discussion doc... perhaps should split off the proposed BCP form.... jb: getting questions about this I-D and it still be ing an I-D, maybe we should finalize the best prac portions and then can keep working on the parts that are still in flux ht: would be nice to come up with list of things that arent addressed as yet -- thinking that we discuss individual unaddressed sec items on list and come to conclusions tl: we need feedb from wg whether the set of pracs is sufficient ht: who has read recent version of doc -- 2 hands (sigh) want hands for folks to comit to review mike, phil, who? kathleen: whos read any ver of doc? ~5 tl: next step to add dynamic oauth issues to doc > * OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution ht: we need to figure out this doc, plus there's some https doc we need to figure out previously we had focused on use cases where we used http signing as a mech but now we have TB, so need to re-eval applicability in jpop and the above doc...opinions? jb: yes shud update arch doc to reflect the archs we are working on ludwig: msg from ACE, we need the jpop spec, so if u would make that great again ACE will refer to it ht: ok so in ACE we are trying to finish up ssome profiles in there -- ludwig: would be good if oauth figure out pop methods so can reuse them PLEASE OAUTH FOLKS: GO READ ACE WG SPECS AND REVIEW THEM!! ht: there's work in another ietf wg trying to figure out http signing...? jr: we have had a servicable approach for this for long time, I've implemented it, the cavage doc is similar approach, the doc from this wg aligns with jose, the other doc does not, it has its own hashing mechs, the cavage doc is similar in how protect headers, but diff in other respects, so there are two dicff approaches, always intent for pop once u get tok with key bound to it, have options, http msg level signing was one of them, but this wg hasnt moved it fwd, but we seem not interested in progressing it, and the cavage doc does not help that. cavage == https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ jr: is an individ submission, floating around for few years, abt same time wrote oauth-http-sigiing... jb: largely agree w/jr -- this is hard and ugly, will break in circumstances -- but jr's approach is decent, so we can ignore it or progress it -- it does decent job, yeah is ugly but that is http -- counter arg is that we dont want to have too many way=s to do something, but some folks really want to do http signing... ht: disc this in berlin, will post mail to list and pose question whether there is interest to this work... lemme know if you have impl'd Brian C. https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-mutual-tls-00.pdf mutual tls profiles for oauth clients: this is distinct from the jpop draft this draft: https://tools.ietf.org/html/draft-campbell-oauth-mtls see slides jr: wud like to see ext'd for use at resource svrs for non-jwt tokens -- it does not have guidance introspection is way to do it -- how might i as deployer make that connection btwn client cert and the token being presented? bc: whats not in there is any specific rcmds wrt what it would look like in introspection context... we shud add that, it's related to TB introspec stuff we mentioned earlyier jb: have some introspec stuff in the jpop draft, it hasnt made it over to this draft yet, wonders about extending introspec such taht the introsp svr can do the verif rather than the other server bc: no, shud do something in context of how things work now jr: that wont work in introsp jr: with BC on this, in early introsp did have way for rs to sent info to as, but took it out cuz the as lacked context, the RS has context to eval stuff. introsp is just to lookup key, do final validtn on RS cuz it has the nec context, if do diff, u r extending trust further than needed bc: pls adopt this draft as WG doc -- it will benefit open banking initiative kathl(km): would like this to progress (ekr is now resp AD for oauth) -- would like to see better options than bearer toks in general tl: supports this as wg doc, also there is psd2 in EU, force banks to open their APIs, EBA RTS specifically calls for mutual cert-based authn ht: hum for adopting this as wg itme? (fairly strong hum) hum against: none ht: will confirm on list > * OAuth 2.0 Device Posture Signals - William > (draft-wdenniss-oauth-device-posture-00) john bradley https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-device-posture-00.pdf working on this with william denniss pkce does not protect agaist app impersonation eg one app using the redirect uri of another app and being malicious so if get attestation from app about devices posture see slides jb: android uses a signed jwt for this and is sorta compatible (this is SafteyNet API result) hannes: what are we standardizing? Real protection by hw doing attestation, why need to define some unprotected fields? jb: because not all these things are in the attestation (eg safetynet) so if the device is not rooted you can trust what the app says.... on ios, having the app tell you that it has a pin lock or not is valuable info -- in getting some info from the app abt its posture is useful tho you also need the OS-level attestation to be comfortable -- the draft goes into all this just didnt put it in the slides, going to talk with moto this afternoon about using this for their 1st responder things... WH announced yesterday $6B firstNet contract (they will be using oauth and OIDC) and in this context they are very sensitive about app security -- this is one of dimensions of oauth we have not really grappled with, for native apps this gives u higher level of security jb: pls read, and wants to have it adopted eventually -- it will help stdz the oauth-level data adam dawes: support this, app attstn aspect is useful, agree lockscreen state is spoofable, but well behaved apps will find it useful. jb: is begging android team to put more info in safetynet philhunt(PH): likes this, nwo have app attstn and dvc attstn, need to link the two? jb: have the two attstns signed by same key and mention each other...(?) ph: need to figure out how to really link the two attstns jb: [mentions some other possibilities dime-reg?] ph: we can work out the details joe saloway: thinks SACM is working on similar stuff -- btw there will be priv cons in all this jb: yes understood. in goog case this is being considered at OS level, they try to prevent correlation ht: yes need to look into privcons km: attstn is popping up in a lot of WGs, here, secevents, and others... jb: note we can give the vendors guidance but not define the attstn formats here mj: there's a list of attstn formats in the w3c webauthn spec fyi ht: who read? 4 folks: Mike, Joe, Rich, Phil ### JOSE/JWT Security Update https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-jwt-security-update-00.pdf mike jones see slides :) Next Steps -Encourage people to keep alerting us about security critical implementation flaws - Catalog and write best practices articles describing implementation pitfalls to avoid - Publish articles at oauth.net? ht: (indivd) on first one, yes. 2nd one, that came up in the aouth sec workshop (plans?). 3d one doesnt seem to happen -- have difficulties on who is implementing libs and deplying, hard to reach the "community" -- even tho we have mailing list to receive sec alerts, folks do not seem to use it... ht: (chair) this is proposing to write yet another doc mj: have AI in secevnet to write jwt best pracs, but that prob belongs here dickhardt(dh): is there a decision to do such a doc? hum? ht: ok so wrt mj's preso, in favor of having such a doc? jwt best pracs hum for: strong hum if obj: none tn: prefer this be part of what torsten (tl) is working on mj: well jwt used lots of non aouth places, so that may not be effective tl: agree w/mike, am not jwt expert ht: have it as sep doc end