########## Token Binding WG - IETF96 Berlin ============= http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-tokbind > * Note Well and Agenda Bashing (5 min) https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-2.pdf let's jump straight to presos... > * Core Documents (55 min) > - draft-ietf-tokbind-protocol-08 -- Andrei Popov https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-0.pdf > - draft-ietf-tokbind-negotiation-03 mostly all editorial changes since ietf-95 -- see slides > - draft-ietf-tokbind-https-05 -- dirk balfanz https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-4.pdf dirk gives demo using canary chrome and google frontend (at a particular endpoint which is an alpha/canary TLS frontend... https://tokbindrptest.appspot.com echo -n | base64 -D | od -Ax -tx1 Update Fetch to support Token Binding -- vinod working on this https://github.com/whatwg/fetch/pull/325 william denis: what about the 302 redirect req -- is that the only way to do things? what about other patterns? dirk(db): we need diff triggers for diff patterns, for patterns that utilize redirects, the response header field in spec is the trigger -- for other patterns, need to write other profiles and define diff patterns -- that's somthing that'll happen in other WGs -- i imagine will work with XHR like: when create XHR obj, have a flag that's 'include-referred-tb' -- in saml world, have an auto-submit form, could have a boolean attr on the page that signals inclusion of the referred TB --- wrt whatwg/w3c, once stuff in fetch, the stuff passed down from higher layer ought to Just Work -- each of these have in comman that there's an origin from which the req is made and one to which the provided and referred TBIDs are sent subodh: what about priv implications of including this referred header field? db: browsers have notions of whether to send 3d party cookies or not, if bwsr is sending out a req in which it is not ok to send 3d party cookies, it will not send TB header wseltzer: when bring this up in webappsec WG ? db: onece Anne gives ok to the PR#325 vinod: probably just weeks until done leif: can these 3 specs goto WGLC? mike jones(mj): maybe you shud ask that question again after my oauth preso, i'll raise an open issue with the core specs... john bradley(jb): hans has a version of mod_ssl that does TB -- any other impls? andrei (ap): have impl in IE & Edge (both use same http engine) subodh: have started working on impl > * Related work: Token Binding for OAUTH (30 min) > - draft-jones-oauth-token-binding-00 --- Mike JOnes https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-3.pdf see slides wrt slide 3 tony nadalin(tn): notes that if connection had gone away might get a lot of reauthns db: notes that TBID lifetime can be long and span multiple tls sessions slide 4: TB ID Tokens defined in: openid-connect-token-bound-authentication-1_0 3-party use case, this seems to work out well given the present tbind specs slide 5: representation in openid connect ID Token they put hast of TBID in ID Token -- saves bytes. an open issue of how to have crypto agility for the hash function b campbell(bc): how bout just define names for hashes algs... slide 6: Tokenbound access tokens see slides... slide 7: issue for TB access tokens this is not using redirects, cross-domain comms is by expicit connection the prob: two channesl not crypto'y bound when using the explicit param method proposed soln: req TB impls to provide APIs for clients to explicitly provide TB info to be sent as referred TB Andrei(ap): pushes back on this notion: "don't need to write any api reqs in a protocol spec" JeffH: well, rfc5929 tls channel bindings does have a section "7. Required Application Programming Interfaces" that is along these lines and serves as a reasonable precedent torsten l.: can see need for such language in the spec, and without it, eg if such api isn't made availaBLE, then TB isn't useful [ tony nadalin, dirk and andrei push back] tn: you put your api reqs into the oauth TB profile spec... mjb: well, ought to be in tb-protocol spec because there's other apps than oauth who'll want to do this johnbradly(jb): thinks such broad language is fine subodh: what does it mean to be a token binding impl -- so does this apply to whom and where and in what context? dick hardt: agree with JeffH and Mike wrt general api guidance justin richer(jabber): This is all about non-browser-based HTTP communication. You *can* do it with the current spec, but there ought to be functional guidance so non-browser apps can all do this the same way. there's no reason for OAuth to be a special snowflake here. william d: either way there's apis to add to tls stack and such guidance makes sense tony(tn): stacks are going to look at their resources to writing api, they can make decisions on their own... jb: unclear whether app on top of stack will have access to the referredTBID, if we pass it as extra param, there's sec issues maybe; if we have an agreement TB will be available to native apps, it'll be easier to developers to have access to this martin thomson(mt): what is this api ? jb: its a native api mt: why is this not simply looking at this "we have simple api, enrich it a BIT" and mike's happy? william d(wd): paramater or header need tls stack cooperation... chair: leif: can someone provide actual text -- this is only a couple lines yes? can do this during WGLC? ?: notes that if we are writing app on top of tls stack and we can't rely on there being an API providing this then life is difficult.... leif: hum on whether we need such api guidance/reqs in the spec ? result: was roughly 50/50 on support and no support for the notion leif: who believes having non-norm guidance is ok? fair hum who believes it is evil? no hum MT: hm, there's possible sec issues here if an app can tell the tls stack to send the TB to some other arbitrary host....? mjb: we're trying to secure existing app comms patterns.... MT: db: so whoever crafts this please include to not violate privacy... bc: MT is getting to convcerns wrt key scoping -- perhaps some guidance wrt scoping in APIs will be necessary... sf: not clear to me that you can craft the sec cons for the full generality of these such API guidance... leif: if we have text, we can actually dicuss more concretely leif: are these specs ready for last call? (various hands go up) lucy lynch(LL): advises that priv review occur before WGLC MT: has priv concerns with this stuff... leif: will you MT do a priv review? LL and WendyS ? u have a month approx before we go into WGLC > - draft-campbell-oauth-tbpkce-00 -- biran campbell https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-1.pdf a TB method for OAuth proof key token exchange... pronounced pixy rfc7636 final slide "what are next steps?" -- questn is more for oauth WG db: one what to think about pkce is it is assym operation, having TB protects against MITM, so yes we should bother jb: it does improve sec, perhaps gets around some impl issues am playing around with TB client IDs... subodh: does this prevent against atks in android & ios where u can register req URLs? jb: pkce does that now Kaoru Maeda: PKCE is to differenciate two apps residing on one device. TBID is associated to TLS connection, that is device to server. Since HTTP/2 requests may coalsce on a single TLS connection, context separation may not be what is desired. end