##########
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